Laurent Sansonetti wrote:
I don't think it's a good idea to provide a way to turn off
optimizations and I do not see the point in benchmarking dead code in
general (I would never do this).
I think it's actually very useful to provide a way to turn off specific
optimizations, if only because they may eventually run into cases where
they break something. But they're also useful when writing benchmarks
that have dead code on purpose...
For some benchmarks it's very difficult to get a reasonable measurement
without forcing some dead code to run. For example, benchmarking a
single local variable access gets completely lost in the method or block
invocation that surrounds it. By forcing several successive local
variable accesses to execute, you get a better picture of what the
actual cost is.
At any rate, if you have good benchmarks for things like local
variables, we can certainly use those for now.
Good to know, I just hope they are not doing this 30 million times in a
loop or something :-)
Well, it gets called numerous times per request.
In the end, though, Rails performance has not actually been very
execution-bound. We've had Ruby code running faster than Ruby 1.8 for
almost two years, but we only recently started to post 10-20%
performance gains for Rails itself. Rails performance, and probably most
large applications' performance, all seem heavily dependent on core
classes being as blazing fast as possible. It's a balancing act, and we
often completely ignore execution performance for a whole release to
work on core classes instead.
Yes, Binding is not implemented yet. Do not worry I have read the MRI
source code and know how Binding works and how to provide a compliant
implementation. Please stay tuned.
Well, I'd certainly like to hear what you're planning for this
particular case. Just let me know when you're ready to talk about it.
I've gone over several options when optimizing JRuby, and the
block-as-binding issue makes most of them infeasible.
- Charlie
_______________________________________________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
