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
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, 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
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
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
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
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 minimal.
The only
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
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_strncpy
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, 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.
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
12 matches
Mail list logo
