Showing content from http://mail.python.org/pipermail/python-dev/attachments/20131118/113e6bcb/attachment.html below:
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 18, 2013 at 4:30 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 19 November 2013 09:57, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
> On Mon, 18 Nov 2013 16:44:59 -0600<br>
> Tim Peters <<a href="mailto:tim.peters@gmail.com">tim.peters@gmail.com</a>> wrote:<br>
>> [Tim]<br>
>> >> But it has a different kind of advantage: PREFETCH was optional. As<br>
>> >> Guido said, it's annoying to bloat the size of small pickles (which<br>
>> >> may, although individually small, occur in great numbers) by 8 bytes<br>
>> >> each. There's really no point to framing small chunks of data, right?<br>
>><br>
>> [Antoine]<br>
>> > You can't know how much space the pickle will take until the pickling<br>
>> > ends, though, which makes it difficult to decide whether you want to<br>
>> > emit a PREFETCH opcode or not.<br>
>><br>
>> Ah, of course. Presumably the outgoing pickle stream is first stored<br>
>> in some memory buffer, right? If pickling completes before the buffer<br>
>> is first flushed, then you know exactly how large the entire pickle<br>
>> is. If "it's small" (say, < 100 bytes), don't write out the PREFETCH<br>
>> part. Else do.<br>
><br>
> Yet another possibility: keep framing but use a variable-length<br>
> encoding for the frame size:<br>
><br>
> - first byte: bits 7-5: N (= frame size bytes length - 1)<br>
> - first byte: bits 4-0: first 5 bits of frame size<br>
> - remaning N bytes: remaining bits of frame size<br>
><br>
> With this scheme, very small pickles have a one byte overhead; small<br>
> ones a two byte overhead; and the max frame size is 2**61 rather than<br>
> 2**64, which should still be sufficient.<br>
><br>
> And the frame size is read using either one or two read() calls, which<br>
> is efficient.<br>
<br>
</div></div>And it's only a minimal change from the current patch. Sounds good to me.<br clear="all"></blockquote><div><br></div><div>Food for thought: maybe we should have variable-encoding lengths for all opcodes, rather than the current cumbersome scheme?<br>
</div></div><br>-- <br>--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)
</div></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4