Roy T. Fielding wrote:
A better optimization might be to reduce the number of calls to
brigade_puts. That's how much of 1.3 was improved.
I only know of three ways to reduce the number of apr_brigade_puts()
calls in 2.0:
* Send fewer fields in the HTTP response header.
* Or do more buffering pr
A better optimization might be to reduce the number of calls to
brigade_puts. That's how much of 1.3 was improved.
Roy
Cliff Woolley wrote:
On Sat, 29 Jun 2002, Cliff Woolley wrote:
some way that would allow us to coalesce the writes.
Alignment issues would kill us here, aren't they? That sucks. G.
Depends on the CPU, but if you are feeling energetic you can also align
the copies. The problem is detect
Cliff Woolley wrote:
On Sat, 29 Jun 2002, Brian Pane wrote:
I tried this, and it didn't unroll the loop. That's probably
because some of information needed to unroll the loop effectively
is unknown to the compiler.
Hm. Okay, well, if we're going to do this, can we split it out into a
sepa
Cliff Woolley wrote:
On Sat, 29 Jun 2002, Cliff Woolley wrote:
some way that would allow us to coalesce the writes.
Alignment issues would kill us here, aren't they? That sucks. G.
We might be able to get some additional improvements by
doing word-at-a-time operations for half
On Sat, 29 Jun 2002, Cliff Woolley wrote:
> some way that would allow us to coalesce the writes.
Alignment issues would kill us here, aren't they? That sucks. G.
On Sat, 29 Jun 2002, Cliff Woolley wrote:
> Also, isn't it true that your patch now causes the buffer bucket to always
> have 0-7 unused bytes at the end?
Oh duh, nevermind on this point, my fault. I misread the loop condition.
--Cliff
On Sat, 29 Jun 2002, Brian Pane wrote:
> I tried this, and it didn't unroll the loop. That's probably
> because some of information needed to unroll the loop effectively
> is unknown to the compiler.
Hm. Okay, well, if we're going to do this, can we split it out into a
separate macro (my_strncp
Cliff Woolley wrote:
On Fri, 28 Jun 2002, Brian Pane wrote:
I remembered why memcpy won't help here: we don't know the
length in advance. But I managed to speed up apr_brigade_puts()
by about 30% in my tests by optimizing its main loop. Does this
patch reduce the apr_brigade_puts() overhead in
> >> The time spent in ap_brigade_puts is
> >> suprising... This particular run indicate that it tool 74355
> >> instructions
> >> to serve a keep alive request.
> >>
> >
> > I've seen the brigade_puts overhead in my testing, too...and it
> > is definitely surprising, since the code is relatively
On Fri, 28 Jun 2002, Brian Pane wrote:
> I remembered why memcpy won't help here: we don't know the
> length in advance. But I managed to speed up apr_brigade_puts()
> by about 30% in my tests by optimizing its main loop. Does this
> patch reduce the apr_brigade_puts() overhead in your test envi
Brian Pane wrote:
Bill Stoddard wrote:
...
The time spent in ap_brigade_puts is
suprising... This particular run indicate that it tool 74355
instructions
to serve a keep alive request.
I've seen the brigade_puts overhead in my testing, too...and it
is definitely surprising, since the code is re
12 matches
Mail list logo
