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
Cliff Woolley wrote:
>
> On Fri, 28 Jun 2002, Ian Holsman wrote:
>
> > do you think that it is worthwhile having a APR function to determine
> > system load ?
>
> That could be nice.
>
You mean like sendmail's getla()??
--
=
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
Ian Holsman wrote:
do you think that it is worthwhile having a APR function to determine
system load ?
I was thinking of adding a feature to mod_defalte which turns it off
if system load goes over a magic number.
I like the idea. But do you really want load (in the Unix sense, i.e.
run queue
On Fri, 28 Jun 2002, Ian Holsman wrote:
> do you think that it is worthwhile having a APR function to determine
> system load ?
That could be nice.
do you think that it is worthwhile having a APR function to determine
system load ?
I was thinking of adding a feature to mod_defalte which turns it off if
system load goes over a magic number.
--Ian
On Fri, 28 Jun 2002, Brian Pane wrote:
> remaining = h->alloc_len - e->length;
> buf = h->base + e->start + e->length;
>
> Shouldn't that be "remaining = h->alloc_len - (e->length + e->start)"?
Ouch, quite likely. Will look into it.
--Cliff
APU_DECLARE(apr_status_t) apr_brigade_write(apr_bucket_brigade *b,
apr_brigade_flush flush,
void *ctx,
const char *str,
apr_size_t nbyte)
{
apr_bucket *e =
15 matches
Mail list logo
