Re:Why Python Is Slow: Looking Under the Hood
by kbenson on Friday November 21, 2014 @11:26PM
(#8644738)
> That wouldn't explain why one regex engine is 5x faster than another. Only looking at the regex engines themselves would tell you that.
It could definitely explain it, but it may not be the best explanation given the facts. I'll definitely concede that it's pure conjecture.
> A representative Perl program would use regexes and contain some logic that processes the results of those regexes.
Sure, depending on what you want to show. Nobody is trying to say Perl is as fast or faster than C, just that relatively, it's fast for the development cost it requires.
>> I think it's more related to the fact that the actions of the regex parsing implementation when optimized sufficiently is very close in implementation to C code that steps through a char array
> I used to think that, but it is really not true unless your regex engine contains a JIT compiler.
I think we're referring to different things, which is mostly my fault for being loose with my terminology. I really only meant close to C in a conceptual manner, which yields some performance benefit by keeping a large chunk of the looping and work storing specific chunks of text low level and in the interpreter. I wasn't trying to imply the regex engine's cost was negligible or the actual machine operations we comparable in a large way.
It could definitely explain it, but it may not be the best explanation given the facts. I'll definitely concede that it's pure conjecture.
> A representative Perl program would use regexes and contain some logic that processes the results of those regexes.
Sure, depending on what you want to show. Nobody is trying to say Perl is as fast or faster than C, just that relatively, it's fast for the development cost it requires.
>> I think it's more related to the fact that the actions of the regex parsing implementation when optimized sufficiently is very close in implementation to C code that steps through a char array > I used to think that, but it is really not true unless your regex engine contains a JIT compiler.
I think we're referring to different things, which is mostly my fault for being loose with my terminology. I really only meant close to C in a conceptual manner, which yields some performance benefit by keeping a large chunk of the looping and work storing specific chunks of text low level and in the interpreter. I wasn't trying to imply the regex engine's cost was negligible or the actual machine operations we comparable in a large way.