5 ms·

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 implic

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?

Eclyps 12y ago
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.
disbelief 12y ago
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 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.
- rafekett 12y ago
  > 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?
  - steveklabnik 12y ago
    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 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.

5 ms·

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 implic

by johnny99 12y ago

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?

Eclyps 12y ago
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.
disbelief 12y ago
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 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.
- rafekett 12y ago
  > 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?
  - steveklabnik 12y ago
    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 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.