On Fri, 21 Dec 2001, Thomas Dodd wrote:
> Date: Fri, 21 Dec 2001 11:01:18 -0600
> Wojtek Pilorz wrote:
>
[...]
>
> > 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
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 m
s Dodd <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: making less faster on large amounts of stdin data
>
>
>
> John Summerfield wrote:
>
> > This is a silly, negative response. If the patch does what Wojtek says,
>
On Fri, 14 Dec 2001, Thomas Dodd wrote:
> Date: Fri, 14 Dec 2001 16:48:58 -0600
> From: Thomas Dodd <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: making less faster on large amounts of stdin data
Sorry for late response; I did n
>
>
> John Summerfield wrote:
>
> > This is a silly, negative response. If the patch does what Wojtek says,
> > the IMV it should be applied to the source.
>
>
> A patch to speed up a strange use of a program is what
> seams silly. less (and more) are interactive. why use
> them in a non int
John Summerfield wrote:
> This is a silly, negative response. If the patch does what Wojtek says,
> the IMV it should be applied to the source.
A patch to speed up a strange use of a program is what
seams silly. less (and more) are interactive. why use
them in a non interactive way? What's t
This is a silly, negative response. If the patch does what Wojtek says,
the IMV it should be applied to the source.
It has no significant impact on its size. I can't tell whether there's
an adverse impact on small machines - if so, then it needs to caclulate
a buffer size and use the and that
Wojtek Pilorz wrote:
>
> try the following (on a machine with 128M or more of RAM):
>
> time perl -e '$n=80; $o=0;
> for ($i=1;$i<= $n; ++$i) {
> $l=sprintf "%s line %8d, offset %10d\n", "="x16, $i, $o;
> print $l;
> $o
Hi all,
I like 'less' very much for viewing data, so its lack of speed
when viewing larger amounts of data coming from pipe was irritating
me.
Unfortunately the time less spends processing data from stdin is
proportional to a square of data size. While the proper fix would
be to improve algorith
Hi all,
I like 'less' very much for viewing data, so its lack of speed
when viewing larger amounts of data coming from pipe was irritating
me.
Unfortunately the time less spends processing data from stdin is
proportional to a square of data size. While the proper fix would
be to improve algorith
10 matches
Mail list logo
