This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author steve.newcomb
Recipients rhettinger, serhiy.storchaka, steve.newcomb
Date 2016-08-30.18:33:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <722ff06a-9b68-4ef6-e76a-d81e3e581577@coolheads.com>
In-reply-to <1472577873.63.0.44596393619.issue27898@psf.upfronthosting.co.za>
Content
On 08/30/2016 01:24 PM, Serhiy Storchaka wrote:
> Serhiy Storchaka added the comment:
>
> According to your profile results all re functions are 2.5-4 times faster under 2.7.12 than under 2.7.6. May be I misinterpret it?
I can't explain the profiler's report.  I'm kind of glad that you, too, 
find it baffling.  Is it possible that the profiler doesn't actually 
work predictably in the multiprocessing context?  If so, one thing I can 
*easily* do is to disable multiprocessing in that code and see what the 
profiler reports are then.  It will take all night, but I'm beginning to 
think it would be worthwhile, because it might point the finger of blame 
at either the multiprocessing module or the re module, but not both at once.

(I originally provided a "disable multiprocessing" capability in that 
code in order to use the Python debugger with it.  It would kind of make 
sense if the profiler had limitations similar to those of the debugger.)
>
> Note that 96-99% of time (2847.099 of 2980.718 seconds under 2.7.6 and 4474.890 of 4519.872 seconds under 2.7.12) is spent in posix.waitpid. The rest of time is larger under 2.7.6 (2980.718 - 2847.099 = 133.619) than under 2.7.12 (4519.872 - 4474.890 = 44.982).
Yeah, I'm beginning to wonder if those strange statistics, too, are 
artifacts of using a single-process profiler in a multiprocessing context.
History
Date User Action Args
2016-08-30 18:33:35steve.newcombsetrecipients: + steve.newcomb, rhettinger, serhiy.storchaka
2016-08-30 18:33:35steve.newcomblinkissue27898 messages
2016-08-30 18:33:35steve.newcombcreate