Hacker News Reader

Comment by johnny99 | Hacker News Reader

I'm intrigued, and would love to hear of anyone's experience using this, particularly in a production environment. One question: does it have performance implications, one way or another?

View on HN

JSON rendering performance is a major concern for most of my Rails apps, and I'm wondering the same thing. I've not used Roar (https://github.com/apotonick/roar) before which is what Trailblazer uses for JSON serialization/deserialization. It seems to be full-featured, but I'm interested to hear how it performs compared to other gems. I currently use OJ + Jbuilder + a ton of fragment caching and it's not great but better than anything else I could find.

> JSON rendering performance is a major concern for most of my Rails apps

I've always wondered why this is the case. Faster JSON libraries don't seem to help. Similar frameworks don't have this problem. It just seems the Rails serialization code is slow in and of itself, it's not what it calls out to. Maybe there's a contention issue somewhere?

There have been some historical issues that should have been sorted out in more recent releases. The TL;DR is that Rails wouldn't actually use your faster gems, even if you thought it was. See https://github.com/rails/rails/pull/12183 for the work that was done to improve this. There was another issue too that detailed the specific problem, but I can't find it right now.

I haven't used it, but read up on it after starting to use the Reform gem. It seems more geared toward forcing cleaner, more encapsulated code, which should make your rails app more maintainable in the long run. I don't think that there's any major functional changes that would impact performance.

Reply on news.ycombinator.com