Well, this is a classic use case when we jump too early on Rails not
understanding the Ruby (or programming in general) to at least a decent
level… let alone the meta-programming stuff.
One should get a good hold of Ruby at least to a level where s/he
understands how the memory mapping is working behind the scenes…
otherwise you can end up writing the piles of junk which is eating up
your server’s memory.
@tam - I am even not sure how can experiment it. Collecting data and
studying in progress.
@sur - I am still cross checking… If you provide any reference link or
data to proof that validation already get cached.
“If you provide any reference link or data to proof that validation
I got a smile when I read the above line.
a humble suggestion:
before finding any proof, you gotta study more about programming and how
the memory space is managed on the runtime.
Do you know what is the difference between a string and a symbol and why
and where symbols are preferred over strings ?
a = “some string”
b = “some string”
b.object_id == a.object_id (watch for the result of this expression)
sym_a = :some_symbol
sym_b = :some_symbol
sym_b.object_id == sym_a.object_id (watch for the result of this
Now, you don’t need to go too far for finding the proof for the
(let alone the Rails production environment, in one process of Ruby, if
Ruby can’t cache the class why would you even use it ?)
user_class = class User; end
another_user_class = class User; end
user_class.object_id == another_user_class.object_id (watch for the
of this expression)
Note:- object_id is the method available to every single object in Ruby
(remember every smallest/biggest entity in Ruby you have is an
and it returns the id of that object from the memory map.
Play as much as possible with the above snippets in IRB. IRB is
Ruby console, you can initiate it by typing “irb” in your terminal and
can type the above snippets to test there.
Try tasting the flavor of Ruby to a bit of the next levels.