headius

9 ms·

61.
by headius 11y ago
Ruby performance has not improved substantially since 2.0, and we should almost always be faster for straight-line workloads. If we're not...tell me.
62.
by headius 11y ago
What do you mean? JRuby can make system calls as fast as MRI, generally. We don't support their C extension API, but we support and maintain an FFI library to programmatically call C from Ruby.
63.
by headius 11y ago
They're a mixed bag because they're benchmarking libraries more than they're benchmarking runtimes. Often the JRuby-specific versions of libraries (e.g. activerecord-jdbc) do not get the same performance attention as the ones
64.
by headius 11y ago
That's generally not true. MRI's straight-line performance has not improved as fast as JRuby's, and if we're ever slower than MRI it's generally something we're doing wrong. When we're doing things right,
65.
by headius 11y ago
We've added a --dev flag to JRuby that attempts to turn on fast-starting flags in JRuby and the JVM to reduce startup time. It can be as much as twice as fast. We continue to try to improve startup performance, and hopefully over the n
66.
by headius 11y ago
This is really an unfortunte side effect of every Rails AR adapter being a one-off piece of code. In JRuby, there's not much code different between the databases, but in Rails they're all completely different. That means we basica
67.
by headius 11y ago
Agreed.
68.
by headius 11y ago
In general everything ActiveRecord does should be supported by JDBC. The pg port is for cases where you need features the JDBC driver does not support but the C driver does, like geocoding etc.
69.
by headius 11y ago
We welcome GAE users of JRuby but they never seemed to be a big segment of the community. And we continue to maintain non-native IO and process logic for limited environments. If that is not sufficient for GAE, we'll work with you to m
70.
by headius 11y ago
Matz himself has said he regrets putting these variables in the language, and some day they may disappear. We'll match behavior as much as possible, but they're a relic no matter how you slice it.
71.
by headius 11y ago
This is not a hard one to fix but it didn't make the final release and had never been reported before, despite being largely the same for 9 years. It will be fixed as soon as we can get to it. I will echo what others have said, though.
72.
JRuby upgrade promises better performance(infoworld.com)
3 points by headius 11y ago|0 comments
73.
JRuby 9000 released(blog.jruby.org)
265 points by headius 11y ago|117 comments
74.
by headius 11y ago
I assume you only measured JRuby at low n, where the startup and warmup time would overshadow overall performance. JRuby is usually significantly faster than C Ruby. In this case, it's nearly twice as fast: [] ~/projects/
75.
by headius 11y ago
It's a decent article but the justification for rewriting is totally discredited by not even having tried JRuby. Many apps drop right in and get true concurrency, better GC, and faster performance for free. It sounds like JRuby wasn&#x
76.
by headius 12y ago
I wouldn't say TFA is lying but it is presenting only part of the truth. MRI does have an actively developed test suite, which they run in CI and which we use to test compatibility in JRuby. MRI has contributed to RubySpec in the past
77.
by headius 12y ago
Brian has been paid to work on Rubinius and RubySpec full time for at least 6 years.
78.
by headius 12y ago
Be wary of this cultivated list of links. There are others out there that would make it very clear why the proposed design process was a misfit given the projects and people involved.
79.
by headius 12y ago
I believe he's shutting it down as a political move. They're still going to use it to maintain Ruby compatibility and they'll still need to run it against MRI. It just isn't a standalone project now.
80.
by headius 12y ago
They have used and contributed to RubySpec in the past, but many (like me) were turned off by the maintainers' attitudes toward contributors and lack of respect. For example, see the zenspider link elsewhere in this thread. Nobody ques
81.
by headius 12y ago
I came to the thread to make sure someone was spreading truth rather than FUD, and this was the first comment I saw. Bless you.
82.
by headius 12y ago
Am I the only one that considers this disgusting? If the GC is so bad that it causes 2-10x slower operation in this use case, then it's a bad GC. I mean really, really bad. Short-lived objects in any modern GC should be swept away triv
83.
Very High Performance C Extensions for JRuby+Truffle(reddit.com)
2 points by headius 12y ago|0 comments
84.
by headius 12y ago
Epic.
85.
by headius 13y ago
I was one of the speakers at this event and I have to say that the organizers really made a heroic effort to ensure we had a good event. Anyone not talking to the organizers did not even realize the stress they were under...they did an amaz
86.
by headius 13y ago
Shown where? Mono's JIT is nowhere near as good as OpenJDK/Hotspot.
87.
by headius 14y ago
Yeah, the Sinatra numbers really ought to be more in line with the straight Rack numbers. Something's amiss. Glad to see that on Rack, where I'd expect us to be fast...we are doing ok. On par with PHP (not a big thing to brag about, perhaps
88.
by headius 14y ago
You can't make a rocket scientist just by giving them carte blanche to play with rockets. I definitely appreciate the empowering aspects of open commit policies, but I'm less concerned with getting contributions than I am with getting good
89.
by headius 14y ago
This policy works for young or small projects. It does not work for larger, more complicated projects. On the JRuby project, we carefully examine all incoming pull requests. At least half of them would break something unintended, and half
90.
by headius 14y ago
Here's a case study showing over 500k connections to a Java instance in 2.5GB of memory using NIO. JRuby's implementation of Ruby's IO is implemented directly atop NIO. So yeah...that 15GB assertion is nonsense. http://urbanairship.com/blo

More ›