Re: Re (tilly) 3: XML::SAX::PurePerl Performance

[Matts]

Points answered in order:

The methods vs functions thing looks bad in a benchmark, but generally only when you have something like 100_000 calls or something like that. And usually only with empty function bodies, like you suggest. So the call itself may appear to be twice as slow, but it doesn't really show up that bad in real life applications. Plus in 5.7.2, Doug MacEachern of mod_perl fame has made it so that sometimes method calls can be faster than function calls (don't ask me how - his voodoo is way beyond mine).

The purpose of next, I admit, has been lost in a series of refactorings. I think it's either time to stop refactoring for speed and try to clean things up, or stop refactoring for speed and fix the remaining compliance issues instead ;-)

I thought read was supposed to buffer too. But I was surprised to see a speedup when I did some buffering of my own. Maybe it only buffers if you ask for a significant number of characters? I have no idea what the internals are of it all, I only know to not believe everything you read, even from gurus ;-)

[tilly]

I don't know that much about the full internals myself, but read is supposed to maintain an internal I/O buffer. However depending on how you configure and compile Perl, and how Perl interacts with the buffering layer(s), the code path that it takes can be very slow in practice.

In particular I have seen people get [id://29807impressive speedups] before by bypassing stdio and just buffering themselves in Perl. That shouldn't be plausible, but it happened. The same code was much slower on Windows. (I don't think it would happen if you compiled Perl to use Perl's I/O layer, but that was not historically the default, and then Perl and C libraries might not cooperate properly...)