Closed carlosdp closed 12 years ago
I'll buy the caching advantages and real-time update reasons to do this. Except we don't really cache anything at the moment.
But, trying to argue that this is beneficial from a server CPU perspective is totally bogus and silly. It certainly doesn't have a positive impact on end-user perceived performance! And, I wouldn't be surprised to find that the resulting code is actually slower on the server because you have to call into ruby twice instead of once and end up generating bigger web pages (which then have to be cached, shipped around, etc.).
Bottom line: If you are doing this for performance it's a premature optimization; show me the numbers!
Ah, obviously it wouldn't really dent our setup, I just mentioned that because it does take the load off of the server. That's not really why I wrote this up, it's because if someone is sitting and messaging people, the timestamps would all continue to say 'a few seconds ago' until they refresh. This way we can keep that up to date without using the push server unnecessarily.
Perhaps I shouldn't have quoted the article since most of it doesn't apply to us. TBH a lot of the optimizations that guy writes are pointless, hence the decreased popularity of the site (except the "after_commit" one, that one actually has a good point). But alas, I assure you it's not for performance reasons =)
As shown here: http://rails-bestpractices.com/posts/105-not-use-time_ago_in_words . This way, the calculation is off of the server and the times can be updated in near real-time efficiently.