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 serhiy.storchaka
Recipients azsorkin, pitrou, python-dev, serhiy.storchaka, vstinner
Date 2015-11-14.14:10:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1447510259.26.0.450784704309.issue24821@psf.upfronthosting.co.za>
In-reply-to
Content
> Could you please push this part of the change? It looks good to me.

Done. The patch that make an optimization now looks much simpler.

> The C library provides a wmemchr() function which can be used to search for a wchar_t character inside a wchar_t* string.

Yes, I know. But this is C99 function, hence we should add configure test for it, and I don't know if it exists on Windows. I did not test its performance.

> Did you try to not use memchr() but a simple C loop for UCS-2 and UCS-4?

A simple C loop is 25-50% slower. My patch tries to use memchr(), but if it founds false positive, runs a simple C loop for limited length. This makes a performance only insignificantly worse in the case of few false positives, but makes it much better in cases of often or grouped together false positives. The common case when there are no false positives is not affected.

MEMCHR_CUT_OFF is heuristic parameter. It is equal to the number of characters for which memchr()/memrchr() and a simple loop work the same time. On my machine it is 10-15 for UCS1 and 20-50 for UCS2 and UCS4 (depending on direction and character width).
History
Date User Action Args
2015-11-14 14:10:59serhiy.storchakasetrecipients: + serhiy.storchaka, pitrou, vstinner, python-dev, azsorkin
2015-11-14 14:10:59serhiy.storchakasetmessageid: <1447510259.26.0.450784704309.issue24821@psf.upfronthosting.co.za>
2015-11-14 14:10:59serhiy.storchakalinkissue24821 messages
2015-11-14 14:10:59serhiy.storchakacreate