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
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
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, I'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 function
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,
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
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
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
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 of
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
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
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: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
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
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
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 like:
27 matches
Mail list logo
