Re^2: Unexpected OO accessor benchmarks

Yup, what he should have done is pass an anonymous coderef instead:

normal => sub { $self->a() },
[download]

Which gives reasonable results:

               Rate    normal optimized    direct
normal     662252/s        --      -15%      -56%
optimized  775194/s       17%        --      -49%
direct    1515152/s      129%       95%        --
[download]

Comment on Re^2: Unexpected OO accessor benchmarks Select or Download Code

Replies are listed 'Best First'.
Re^3: Unexpected OO accessor benchmarks by cLive ;-) (Prior) on Feb 09, 2007 at 20:23 UTC
Thank you - I feel much better now. Oh the fun of pre-processing... `Rate normal optimized direct normal 172740/s -- -28% -60% optimized 239252/s 39% -- -45% direct 433898/s 151% 81% --` [download] That looks a little more like what I expected.	[reply] [d/l]
Re^4: Unexpected OO accessor benchmarks by Fletch (Bishop) on Feb 09, 2007 at 20:42 UTC
It's not preprocessing. You pass a hashref to `cmpthese`, the values of which are computed when that line of code is executed. Those values in this case are method invocations which are evaluated where they occur. It should be no more surprising than `some_sub( $obj->method() )` calling that sub with the value returned from the method call.	[reply] [d/l] [select]
Re^5: Unexpected OO accessor benchmarks by cLive ;-) (Prior) on Feb 10, 2007 at 00:55 UTC
I should have probably not mentioned pre-processing out of context :) The code I'm analyzing is going to be optimized before publishing. So all calls of type a() would be replaced using a regex with type c() throughout the codebase, and then the accessor sub can be deleted. Assuming the gains are worth it in terms of performance increase - but that's what I'm trying to determine ;-)	[reply]
Re^6: Unexpected OO accessor benchmarks by eric256 (Parson) on Feb 10, 2007 at 02:29 UTC