homepage

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 pitrou
Recipients benjamin.peterson, daniel.urban, jcon, nirai, pitrou, stutzbach, vstinner
Date 2011年05月10日.09:26:12
SpamBayes Score 1.6653345e-16
Marked as misclassified No
Message-id <1305019569.3569.6.camel@localhost.localdomain>
In-reply-to <1304896386.11.0.128008274277.issue9971@psf.upfronthosting.co.za>
Content
> Based on the above I think you are right about using the internal buffer
> regardless (revision attached). You pay a price with larger buffer sizes but on
> balance it seems to be a much better general purpose solution. The java-like 
> solution is decent as well, it is only slightly slower for small reads and optimal
> for larger buffer sizes.
Thanks for the measurements!
The way the loop is written is a bit quirky, can't the flow be made more
sequential:
+ if (n > 0) /* short circuit */
+ goto drain;
+ if (n == 0 || (n == -2 && written > 0))
+ break;
+ if (n == -2) {
+ Py_INCREF(Py_None);
+ res = Py_None;
+ }
+ goto end;
Also, it seems you don't have the unlocked fast path for small reads
anymore (when they can be serviced in whole from the buffer).
> Interestingly enough it seems like using read() is a better idea
> if you use a smaller size (how is that right?).
That's interesting indeed. Perhaps that is due to the overhead of
getting a Py_buffer to the readinto() argument. It would be nice to
optimize it, but it's probably outside the scope for this issue.
(it also shows that our allocator does quite well with small objects)
History
Date User Action Args
2011年05月10日 09:26:13pitrousetrecipients: + pitrou, vstinner, benjamin.peterson, stutzbach, nirai, daniel.urban, jcon
2011年05月10日 09:26:12pitroulinkissue9971 messages
2011年05月10日 09:26:12pitroucreate

AltStyle によって変換されたページ (->オリジナル) /