On Sat, Jan 30, 2010 at 3:03 PM, Jacob Rief jacob.r...@gmail.com wrote:
Please just don't add anything new. If you are unhappy with what
ZeroCopy{Input,Output}Stream provide, you can always just create your own
stream framework to use.
Well, I have to live with that decision. Maybe in
Hello Kenton,
2010/1/30 Kenton Varda ken...@google.com:
We can't add a new virtual method to the ZeroCopyInputStream interface
because it would break existing implementations.
but only on a binary level. God's sake you are not Microsoft :)
Besides that, it's unclear what the Reset() method
We can't add a new virtual method to the ZeroCopyInputStream interface
because it would break existing implementations.
Besides that, it's unclear what the Reset() method means in an abstract
sense. Yes, you can define it for the particular set of streams that you're
thinking of, but what does
Your new results seem to indicate that the extra malloc/free can cost
between 300ns and 1500ns. At the low end, the overhead is negligible and
not worth complicating the interface. At the high end, your results seem
hard to believe, unless your memory allocator is extremely poor. And even
if
Hello Kenton,
2010/1/20 Kenton Varda ken...@google.com:
(1) Normally micro-benchmarks involve running the operation in a loop many
times so that the total time is closer to 1s or more, not running the
operation once and trying to time that. System clocks are not very accurate
at that scale,
Can you send me the complete source file for this benchmark?
On Thu, Jan 21, 2010 at 11:50 AM, Jacob Rief jacob.r...@gmail.com wrote:
Hello Kenton,
2010/1/20 Kenton Varda ken...@google.com:
(1) Normally micro-benchmarks involve running the operation in a loop
many
times so that the total
(1) Normally micro-benchmarks involve running the operation in a loop many
times so that the total time is closer to 1s or more, not running the
operation once and trying to time that. System clocks are not very accurate
at that scale, and depending on what kind of clock it is, it may actually
Hello Kenton,
What makes you think it is inefficient? It does mean the buffer has to be
re-allocated but with a decent malloc implementation that shouldn't take
long. Certainly the actual reading from the file would take longer. Have
you seen performance problems with this approach?
Well,
