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 Arfrever, alexandre.vassalotti, asvetlov, neologix, pitrou, rhettinger, serhiy.storchaka
Date 2013-04-27.17:44:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> Padding makes it both less efficient and more annoying to handle, IMO.

Agree. But there is other application for NOPs. UTF-8 decoder (and some other decoders) works more fast (up to 4x) when input is aligned. By adding several NOPs before BINUNICODE so that start of encoded data is 4- or 8-bytes aligned relatively to start of frame, we can significan speedup unpickling long ASCII strings. I propose to add new NOP opcode and to use it to align some align-sensitive data.

> My framing proof-of-concept ends up quite simple in terms of code
> complexity. For example, the C version only adds 125 lines of code in 3
> additional functions.

I just looked in the code and saw that the unpickler already has a ready infrastructure for prefetching. Now your words have not appear to be so incredible. ;) It should work.

> No doublecopying is necessary (not in the C version, that is).

Agree, there is no doublecopying (except for large bytes objects).
Date User Action Args
2013-04-27 17:44:34serhiy.storchakasetrecipients: + serhiy.storchaka, rhettinger, pitrou, alexandre.vassalotti, Arfrever, asvetlov, neologix
2013-04-27 17:44:34serhiy.storchakasetmessageid: <>
2013-04-27 17:44:34serhiy.storchakalinkissue17810 messages
2013-04-27 17:44:33serhiy.storchakacreate