Wojtek Pilorz wrote:
> I have made some more experiments with less;
> I am attaching two patches;
> less346_bufsize32k.diff one is like the previous one, except
> that buffer size is 32k, which seems to be enough, and is power of 2, so
> division, multiplication and remainder may be computed more efficiently
> (the compiler might convert those operations to shifts and masks).
>
> less346_bufsize_env.diff is an attempt so see what the impact of allowing
> user-defined value would be;
<snip>
> As can be seen from the tests timings, there is little gain (when processing
> 40 MB of data on pipe) with increasing buffer size above 32KB, and the price
> for having the buffer size user-specified (using my suboptimal implementation)
> is slowed down by about 30%. Please keep in mind that original less, using 1KB
> buffers would need more than 500 seconds for the same operation.
I like the one based on ENV settings better. It's not the fastest
in any situation, but would allow the 1K default unless a change
was needed.
Would calculating the size of the buffer (sizeof(struct buf)+LBUFSIZE-1)
once and reusing it make the difference in static-v-dynamic
size speed it up?
Should it be and ENV variable, command line option
(which could be added to $LESS)
Have you played with the less command line options
for buffers? Did they help? (the -B and -bn options)
It appears you can specify the number of buffers
at startup, so the code to allocate buffers is only
run once. but then you can only go back that far since
the whole file isn't buffered.
This might work better in some situations. The developers
added it for some reason :) Maybe it was intended for
this king of speed-up.
-Thomas
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
