Re^2: Why "Modern Perl" is slower than "Legacy Perl"?

I just noted that threaded perls all came in much slower than unthreaded perls.

You sound surprised. I'd gather from your years on p5p that you would know.

For the rest of the world, it's a known fact that a perl build with thread support is significantly slower than a perl build without thread support (the ability to do threads is already enough for the slowdown - it's a price you pay regardless whether you actually use threads or not). This is why Perl by default (that is, after a ./Configure -d) is build without thread support.

Comment on Re^2: Why "Modern Perl" is slower than "Legacy Perl"? Select or Download Code

Replies are listed 'Best First'.
Re^3: Why "Modern Perl" is slower than "Legacy Perl"? by Tux (Canon) on Jul 04, 2011 at 08:06 UTC
I'm not surprised that threaded perl builds are slower. I know. I also know that the impact is much less now in more recent perl builds that it was in older perl versions. I can see on a day-to-day basis what the impact is of threads vs non-threads in my smoke status. Today it shows `threaded is 5.3% slower than non-threaded`. Look at the bottom. I hereby would put the word "significantly" into a bit of a context. I still think that 5.3% is significant enough to not want a threaded perl build, as I NEVER ever saw the need for threads. With more and more (useful) perl applications actually using threads (e.g. Padre won't even run without them), I can see people wanting them. For me any app requiring threads is reason enough to not even try it. Enjoy, Have FUN! H.Merijn	[reply] [d/l]
Re^4: Why "Modern Perl" is slower than "Legacy Perl"? by Anonymous Monk on Jul 04, 2011 at 08:32 UTC
Threads make Win32 more bearable :)	[reply]