Message199456
| Author |
pitrou |
| Recipients |
barry, christian.heimes, kristjan.jonsson, pitrou, vstinner |
| Date |
2013年10月11日.09:51:56 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1882276521.68616056.1381485110088.JavaMail.root@zimbra10-e2.priv.proxad.net> |
| In-reply-to |
<1381484623.53.0.461303636568.issue19219@psf.upfronthosting.co.za> |
| Content |
> This looks fine. Can you quantify where the speedup comes from?
From all changes, but mainly the ASCII special-casing and the new
buffering.
> Reading the code, I see we now maintain a small internal buffer in
> the file object, rather than using stack allocation at the call
> sites. It is unclear to me how this saves memory, since the amount
> of memory copying should be the same.
No, memory copying is suppressed in many cases.
> Have you looked at providing a special opcode for a few other magic
> numbers?(We have that in our own custom marshal format)
> Some very common values are:
> empty tuple
> 0
> 1
It shouldn't be useful since marshal memoizes them anyway: only the
first appearance in a pyc file would benefit. |
|