Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache serializers for class #833

Merged
merged 4 commits into from
Mar 13, 2015

Conversation

lsylvester
Copy link
Contributor

Currently, each time a model is serializer is tries to look up the Serializer class using safe_constantize. This can be slow when serializing a large number of models.

This adds a cache to return the serializer class for each class, which reduced the amount of time looking up the serializer classes.

@joaomdmoura
Copy link
Member

👍 It seems good to me. @joshsmith ?

@@ -199,16 +199,22 @@ def serializer_from_options(options)
opts
end

def self.serializers_cache
@serializers_cache ||= ThreadSafe::Cache.new
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not very familiar with this. Can you explain what this does and whether there are any potential side effects?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

btw it would generate a new dependency with thread_safe gem right?
Is there some reason to not use ActionController::Base.cache_store

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's correct, and I see no reference to ThreadSafe elsewhere. That concerns me a little.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Threadsafe is a dependancy of ActiveSupport, so it is already indirectly as dependancy. I can add it is explicitly as a dependancy.

The reason that to use it instead of ActionController::Base.cache_store is that is in purely in memory so is faster than going to an external cache like memcached which ActionController::Base.cache_store would do.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. Well, it seem cool for me as we are talking about small things.
Can it cause some problem to not-quit-amazing-servers with less memory ir is it derisive?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed ActiveSupport::TimeZone.zones_map in Rails 4.1 is using ThreadSafe::Cache, as you can see here and here.
Okay, I think it's enough to make me feel comfortable about it. cc/ @kurko @joshsmith @guilleiguaran

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree then, but really appreciate the discussion on it. Thanks for obliging us @lsylvester! 🏆

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you remove the hardcoded dependency? That way, if Rails removes it AMS tests will explode and we'll me notified that we need to do something about it (either leave it or replace it, in case there is a better alternative).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kurko the dependency has been removed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 great work @lsylvester
Thank you!

@kurko
Copy link
Member

kurko commented Mar 11, 2015

Summoning @guilleiguaran.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants