On 02/05/2011 10:36 AM, Nick Sabalausky wrote:
On a separate note, I think a good way of testing the design (and end up
getting something useful anyway) would be to try to use it to create a range
that's automatically-buffered in a more traditional way. Ie, Given any input
range 'myRange', "buffered(myRange, 2048)" (or something like that) would
wrap it in a new input range that automatically buffers the next 2048
elements (asynchronously?) whenever its internal buffer is exhausted. Or
something like that. It's late and I'm tired and I can't think anymore ;)
That's exactly what I'm expecting.
Funnily enough, I was about to start a thread on the topic after reading
related posts. My point was:
"I'm not a specialist in efficiency (rather the opposite), I just know there is
--theoretically-- relevant performance loss to expect from unbuffered input in
various cases. Could we define a generic input-buffering primitive allowing
people to benefit from others' competence? Just like Appender."
Denis
--
_________________
vita es estrany
spir.wikidot.com
