08 Nov 2010 - Warsaw
Instead of introduction
It all started here, on Spree google group after I’ve released skeleton of extension allowing to integrate edge Spree with Globalize3
Some history of ‘Globalize is slow’
Globalize1 kept all the translations in one table and therefore used polymorphic associations (and, I don’t remember exactly, but possibly every single translated field had its own row). Which of course was slow as hell after the number of translated stuff grew considerably.
Additionally the problem of N+1 queries (for each product on page there was a query for getting its translated fields, each one slow already by itself) was hard to circumvent due to mixed philosophy of catch-all (single polymorphic table) and atomicity (each field in separate row).
There were of course attempts to hack it but the damage has been done and thus Globalize has become known as a serious performance hog.
Globalize done right
Globalize2 — and, by extension, Globalize3 which is basically “2” but rewritten for Rails3 compatibility allowing for cleaner code and API — used a different approach. Every translated model has it’s own “something_translations” table, consisting of columns with translated values (and, of course, locale for which it’s used). Which is not a very surprising design decision, provided both were developed mostly by Sven Fuchs, the author of the blog post linked above.
Now, theoretically the problem of N+1 queries is still here (every single item needs to query for a single row from product_translations), but it’s hell of a lot easier to prevent it now:
class Product
translates :name, :description
named_scope :with_translations, :include => :translations
# or even, for maximum comfort
default_scope :include => :translations
endI’ve been using Globalize2 for some time now in my
store
and using the above solution doesn’t impair performance at all, the
app is super-fast.
Conclusion
Simple and short, as shown above — given the current state of Globalize, its “slowness” is just a thing of the past.