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
Justin Erenkrantz wrote:
IIRC, I did macroize it during my test runs (at one point at least -
I may not have committed it) and found no performance improvement.
The problems seemed to be with the function pointer itself. It's all
a little fuzzy though, so it's possible I didn't macroize.
A bett
On Fri, 28 Jun 2002, Justin Erenkrantz wrote:
> p->alloc
> and
> #define apr_palloc(...) p->alloc
None, but that's not what we were doing with SMS.
> to the fact that we used to have a function like this:
>
> apr_palloc()
> {
> return p->alloc();
> }
Yeah, but it did even more. It was more l
On Fri, Jun 28, 2002 at 12:22:01PM -0700, Brian Pane wrote:
> I think SMS's use of a wrapper function to do the indirect method
> call was the main problem, which is why we'd have to use a macro
> instead if we reintroduced a function pointer model.
Count me confused, but what is the difference be
Justin Erenkrantz wrote:
On Fri, Jun 28, 2002 at 12:11:09PM -0700, Brian Pane wrote:
I want to break something: binary compatibility for the pool API.
This has been on my list for a long time, but I haven't yet had
time to implement it.
What I'm thinking of is the following:
* Preface the apr_po
At 02:11 PM 6/28/2002, Brian Pane wrote:
I want to break something: binary compatibility for the pool API.
This has been on my list for a long time, but I haven't yet had
time to implement it.
What you are describing is [was] SMS.
Even with the opaque structure, we are still facing derefs that will
On Fri, 28 Jun 2002, William A. Rowe, Jr. wrote:
> >What I'd like to propose is that we document that, for any given status
> >code, _more_ than one APR_STATUS_IS* macro can match, and it's the
> >programmer's responsibility to decide in what order to make the tests.
+1
--Cliff
At 02:43 PM 6/28/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
Since we're talking about semantics, breakage, etc, I'll take the
opportunity to bore everybody with an issue I'd like resolved, too;
Namely, the semantics of the APR_STATUS_IS_* macros.
I've said several times before that APR_STATUS
Since we're talking about semantics, breakage, etc, I'll take the
opportunity to bore everybody with an issue I'd like resolved, too;
Namely, the semantics of the APR_STATUS_IS_* macros.
I've said several times before that APR_STATUS_IS_ENOENT and
APR_STATUS_IS_ENOTDIR don't have the same meani
On Fri, 28 Jun 2002, William A. Rowe, Jr. wrote:
> If it is used by -anybody- they trust the existing implementation.
> That said, it should behave sensibly. The fact that you've asked three
> times says you want to change it.
Hehehehe You noticed? :) Sorry to be a pest, I'm just getting sick
> On Fri, Jun 28, 2002 at 12:11:09PM -0700, Brian Pane wrote:
> > I want to break something: binary compatibility for the pool API.
> >
> > This has been on my list for a long time, but I haven't yet had
> > time to implement it.
> >
> > What I'm thinking of is the following:
> >
> > * Preface the
If it is used by -anybody- they trust the existing implementation.
That said, it should behave sensibly. The fact that you've asked three
times says you want to change it.
Make it so ;-)
Bill
At 01:38 PM 6/28/2002, Cliff Woolley wrote:
On Fri, 28 Jun 2002, William A. Rowe, Jr. wrote:
> IMHO, the i
On Fri, 28 Jun 2002, Justin Erenkrantz wrote:
> Sounds like SMS. We could never overcome speed limitations and we
> always seemed to place blame on the function pointers as the reason
> why the SMS performance wasn't as good as pools.
We had function pointers *and* wrapper functions. We never t
On Fri, Jun 28, 2002 at 12:11:09PM -0700, Brian Pane wrote:
> I want to break something: binary compatibility for the pool API.
>
> This has been on my list for a long time, but I haven't yet had
> time to implement it.
>
> What I'm thinking of is the following:
>
> * Preface the apr_pool_t stru
I want to break something: binary compatibility for the pool API.
This has been on my list for a long time, but I haven't yet had
time to implement it.
What I'm thinking of is the following:
* Preface the apr_pool_t structure with a set of function
pointers for the pool's "methods": alloc, free, d
On Fri, 28 Jun 2002, William A. Rowe, Jr. wrote:
> IMHO, the implementation is what people have tested, not the documented
> behavior. Use the source, luke :-)
But what I'm saying is that I don't think anybody *has* tested it. I
couldn't find a single use case in Apache where the called functio
At 01:22 PM 6/28/2002, you wrote:
On Fri, 28 Jun 2002, William A. Rowe, Jr. wrote:
> If Cliff wants to commit the semantic change to apr_table_[v]do, I'll
> +1 here and raise you a _NONSTD correction. Along with Sander's
> changes to make the unsafe transparent apr_allocator.h structure
> opaque,
On Fri, 28 Jun 2002, William A. Rowe, Jr. wrote:
> If Cliff wants to commit the semantic change to apr_table_[v]do, I'll
> +1 here and raise you a _NONSTD correction. Along with Sander's
> changes to make the unsafe transparent apr_allocator.h structure
> opaque, I'd say we have a bit of worthwhi
On Fri, 28 Jun 2002, William A. Rowe, Jr. wrote:
> I have one bit that must be broken before 1.0, and cannot be remedied easily.
> I'd like to simply break these things before Apache 2.0.40 is tagged.
+1 on all counts. 2.0.40 will already require a full recompile anyway.
Other users of APR must
I have one bit that must be broken before 1.0, and cannot be remedied easily.
I'd like to simply break these things before Apache 2.0.40 is tagged.
apr_pstrcatv should have never been declared _NONSTD, it was and there
isn't much we can do about it without breaking binary compat or introducing
a re
31 matches
Mail list logo
