On Sun, Sep 29, 2002 at 06:55:27PM -0700, Brian Pane wrote:
> On Sun, 2002-09-29 at 17:19, Greg Stein wrote:
>...
> > One thing I just realized, though: if there is no flush function, then a
> > transient could be a problem. I just double-checked apr_brigade_write() and
> > it switches over to HEAP
On Sun, 2002-09-29 at 17:19, Greg Stein wrote:
> On Sun, Sep 29, 2002 at 01:05:38AM -, [EMAIL PROTECTED] wrote:
> > brianp 2002/09/28 18:05:38
> >
> > Modified:buckets apr_brigade.c
> > Log:
> > Rewrite of apr_brigade_writev(). It's now more efficient for
> > both large and
On Sun, Sep 29, 2002 at 01:05:38AM -, [EMAIL PROTECTED] wrote:
> brianp 2002/09/28 18:05:38
>
> Modified:buckets apr_brigade.c
> Log:
> Rewrite of apr_brigade_writev(). It's now more efficient for
> both large and small inputs: zero-copy for data larger than 8KB,
> fewer o
William A. Rowe, Jr. wrote:
At 01:32 PM 7/2/2002, Cliff Woolley wrote:
On 2 Jul 2002 [EMAIL PROTECTED] wrote:
> wrowe 2002/07/02 11:20:57
>
> Modified:buckets apr_brigade.c
> Log:
> New emit on win32. Since this is a heap bucket, we are always
dealing
> in start offsets tha
At 01:32 PM 7/2/2002, Cliff Woolley wrote:
On 2 Jul 2002 [EMAIL PROTECTED] wrote:
> wrowe 2002/07/02 11:20:57
>
> Modified:buckets apr_brigade.c
> Log:
> New emit on win32. Since this is a heap bucket, we are always dealing
> in start offsets that fit in apr_size_t. This do
On 2 Jul 2002 [EMAIL PROTECTED] wrote:
> wrowe 2002/07/02 11:20:57
>
> Modified:buckets apr_brigade.c
> Log:
> New emit on win32. Since this is a heap bucket, we are always dealing
> in start offsets that fit in apr_size_t. This doesn't need the file
> sized apr_off_t
On Thu, May 30, 2002 at 04:25:13PM -0700, Greg Stein wrote:
> Just for sanity's sake... you had sent this to me for review. Obviously, I
> didn't get to it before you checked it in :-) But I just reviewed it. It
> looks great!
>
> I've CC'd Ben Collins to try this on his large SVN repository to se
On Tue, May 28, 2002 at 09:07:35PM -, [EMAIL PROTECTED] wrote:
> jwoolley02/05/28 14:07:35
>
> Modified:buckets apr_brigade.c
> Log:
> Refactor apr_brigade_write() one more time to regain a bit of behavior
> that was lost when check_brigade_flush() was removed, which is that
>
> From: Greg Stein [mailto:[EMAIL PROTECTED]
>
> On Thu, May 23, 2002 at 05:13:22PM -0400, Cliff Woolley wrote:
> > On Thu, 23 May 2002, Greg Stein wrote:
> >...
> > > At some point, apr_brigade_write() got broken. When the HEAP
bucket at
> the
> > > end of the brigade fills up, the flush functio
On Thu, May 23, 2002 at 05:21:25PM -0400, Cliff Woolley wrote:
> On Thu, 23 May 2002, Cliff Woolley wrote:
> > > At some point, apr_brigade_write() got broken. When the HEAP bucket at the
> > > end of the brigade fills up, the flush function should be called. The
> > > current code allocates *anoth
On Thu, May 23, 2002 at 05:13:22PM -0400, Cliff Woolley wrote:
> On Thu, 23 May 2002, Greg Stein wrote:
>...
> > At some point, apr_brigade_write() got broken. When the HEAP bucket at the
> > end of the brigade fills up, the flush function should be called. The
> > current code allocates *another*
On Thu, 23 May 2002, Cliff Woolley wrote:
> > At some point, apr_brigade_write() got broken. When the HEAP bucket at the
> > end of the brigade fills up, the flush function should be called. The
> > current code allocates *another* heap bucket. With this logic, it is
> > possible to grow a brigade
On Thu, 23 May 2002, Greg Stein wrote:
> All right. I'll change my vote from a -1 to a -0, with several changes to
> the function:
>
> * stop the insanity of calling buckets "e". name the variable "bkt" or
> "last_bkt" or *something* besides "e". I'm not sure how the stupid
> convention got st
[ following up, per Cliff's notes in httpd's STATUS ]
On Mon, May 13, 2002 at 05:50:04PM -0700, Brian Pane wrote:
> Greg Stein wrote:
> >-1 on this commit, pending further explanation. I'm loathe to see all of
> >that extra code go in there for a dubious performance benefit. Are you
> >*truly* sav
>
> > At the same time, the brigade_write() family can be tricky to maintain at
> > times. It's much better than it used to be (now that
> > check_brigade_flush() has been burned at the stake), though.
> >
> > So the real question is this: is it ever possible for strlen()+memcpy() to
> > be faste
Greg Stein wrote:
Ouch...
-1 on this commit, pending further explanation. I'm loathe to see all of
that extra code go in there for a dubious performance benefit. Are you
*truly* saving any time? I see a while() loop in there copying data. Isn't
it almost always faster to let the compiler produce an
On Mon, May 13, 2002 at 07:07:44PM -0400, Cliff Woolley wrote:
> On Mon, 13 May 2002, Greg Stein wrote:
>
> > Well, the *compiler* might not, but it can inline the assembler forms which
> > do optimized copies (e.g. whole words at a time).
>
> That's what loop unrolling and memory access coalesci
On Mon, 13 May 2002, Greg Stein wrote:
> Well, the *compiler* might not, but it can inline the assembler forms which
> do optimized copies (e.g. whole words at a time).
That's what loop unrolling and memory access coalescing are for. :)
> We really cannot continue to add complexity to the codeb
On Mon, May 13, 2002 at 06:52:37PM -0400, Cliff Woolley wrote:
>...
> to copy. And no, the compiler won't do an optimized memcpy here because
> the length is not known at compile time. So it's a valid optimization.
Well, the *compiler* might not, but it can inline the assembler forms which
do op
On Mon, 13 May 2002, Greg Stein wrote:
> Ouch...
>
> -1 on this commit, pending further explanation. I'm loathe to see all of
> that extra code go in there for a dubious performance benefit. Are you
> *truly* saving any time? I see a while() loop in there copying data.
> Isn't it almost always fas
Ouch...
-1 on this commit, pending further explanation. I'm loathe to see all of
that extra code go in there for a dubious performance benefit. Are you
*truly* saving any time? I see a while() loop in there copying data. Isn't
it almost always faster to let the compiler produce an optimized memcpy
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 10, 2002 9:44 AM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: apr-util/buckets apr_brigade.c
>
> jwoolley02/04/10 09:44:11
>
> Modified:buckets apr_brigade.c
> Log:
> T
On 16 Aug 2001 [EMAIL PROTECTED] wrote:
> rbb 01/08/16 00:13:07
>
> Modified:buckets apr_brigade.c
> Log:
> If we ask to partition a brigade past the end of the brigade, that is
> not an error condition. At worst, that is a STATUS condition, that we
> should report to the c
On Wed, Feb 28, 2001 at 11:46:39AM -0500, Cliff Woolley wrote:
>...
> HUGE_STRING_LEN comes from apr_lib.h, not from within aprutil, and other
> parts of APR (and maybe Apache, too) are using it. It ought to be
> namespace protected (APR_HUGE_STRING_LEN) (don't I remember past
> discussion about t
On Wed, 28 Feb 2001 [EMAIL PROTECTED] wrote:
> I like making APR_BUCKET_BUFF_SIZE == 8192 [and using it]
Okay, I'll do that.
> and removing the other.
HUGE_STRING_LEN comes from apr_lib.h, not from within aprutil, and other
parts of APR (and maybe Apache, too) are using it. It ought to be
name
On Wed, 28 Feb 2001, Cliff Woolley wrote:
> On 28 Feb 2001 [EMAIL PROTECTED] wrote:
>
> >buf = malloc(APR_BUCKET_BUFF_SIZE);
> >b = apr_bucket_heap_create(buf, APR_BUCKET_BUFF_SIZE, 0,
> > NULL);
>
> On a side note, we currently have two macros that do almost the s
On 28 Feb 2001 [EMAIL PROTECTED] wrote:
>buf = malloc(APR_BUCKET_BUFF_SIZE);
>b = apr_bucket_heap_create(buf, APR_BUCKET_BUFF_SIZE, 0, NULL);
On a side note, we currently have two macros that do almost the same
thing: APR_BUCKET_BUFF_SIZE (=9000) which determines t
On 28 Feb 2001 [EMAIL PROTECTED] wrote:
>buf = malloc(APR_BUCKET_BUFF_SIZE);
>b = apr_bucket_heap_create(buf, APR_BUCKET_BUFF_SIZE, 0, NULL);
>APR_BRIGADE_INSERT_TAIL(bb, b);
> +b->length = 0; /* We are writing into the brigade, and
>
28 matches
Mail list logo
