On Nov 29, 2008, at 2:19 PM, Brian Takita wrote:
On Fri, Nov 28, 2008 at 1:17 PM, Student <[EMAIL PROTECTED]
spring.net> wrote:
Performance is one of those nasty things that can go from being a
non-
issue to THE issue (next to correctness) in the blink of an eye.
I am
curious, however. How much total performance difference did this
change make? I'm betting <1%.
Yeah, this seems like premature optimization, if this were the only
reason. Rspec does not call class << foo nearly 10000 times.
Even if rspec did use class << foo 10000 times (each of which can
define multiple methods), it would make 0.x seconds of a difference in
the worst case (each class << object block only defines one method)
and 0.0x seconds difference in the best case (one object with 10000
methods defined in it).
Most certainly. Although there are certainly other performance
optimizations which would be easy to do, and it would be hard to
calculate how much time they actually cost. For instance, using
"return" actually performs a C longjmp (and the ruby interpreter does
nothing to remove return from the last statement in a method), so
it's more efficient to avoid it - but how much could it really shave
off a user's test suite time?
In this respect, RSpec can be seen more as library then an end-user
program, and it's hard to anticipate *exactly* how the library is
going to be used. For instance, maybe mocks are barely used, but
certain matchers are used heavily. With a large enough test suite
and some good performance analysis these bottlenecks would become
clear, *BUT* the slowdown would be dependent on the *nature* of the
test suite.
Scott
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
