Antoine Pitrou <pit...@free.fr> added the comment:
> 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)
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
