On Mon, Nov 12, 2001 at 07:27:24PM +0100, Mladen Turk wrote:
MT I'm sending you the CRC that I'm using for a long time (from snippets).
MT
MT MT.
MT
MT
MT [-- Anhang #2: crc_32.c --]
MT [-- Typ: application/octet-stream, Encoding: quoted-printable, Size: 4.0K --]
MT
MT [--
On Sun, 4 Nov 2001, Brian Pane wrote:
3. Keep using apr_table_t for the fields in request_rec, and redesign
the internals of apr_table_t to support O(log(n)) access
whatever you do please remember to make sure you don't consume lots of
extra memory for the many tables which have only 1 or
-Original Message-
From: Brian Pane [mailto:[EMAIL PROTECTED]]
Sent: Sunday, November 11, 2001 8:15 PM
To: [EMAIL PROTECTED]
Subject: Re: [PATCH] apr_table WAS: What to do about tables?
My +1 would be non-binding, but IMHO it makes sense to keep
optimizing your new version
From: Mladen Turk [EMAIL PROTECTED]
Sent: Monday, November 12, 2001 11:39 AM
Someone has the idea how to measure those precisely?
Are you testing loopback, or from another machine? Local testing is
generally faulty, and on Win32, it's doubly so (since there are a number
of framing issues
Title: RE: [PATCH] apr_table WAS: What to do about tables?
Mladen Turk [EMAIL PROTECTED] wrote:
[...]
Here is the drop-in replacement for apr_table that uses hash indexes to
table entries.
I've tested the code to the current httpd from cvs.
Well, the performance gain isn't as high
-Original Message-
From: Brian Pane [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 12, 2001 7:03 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [PATCH] apr_table WAS: What to do about tables?
It's hard to measure the effectiveness of a change like
this with ab, because the time spent
Greg Stein wrote:
On Mon, Nov 12, 2001 at 10:02:43AM -0800, Brian Pane wrote:
...
By the way, I have an alternate implementation of a
table speedup that I wrote late yesterday. It caches
a 32-bit checksum for each key in the table and compares
checksums to decide whether it can skip the
-Original Message-
From: Brian Pane [mailto:[EMAIL PROTECTED]]
Sent: 8. studeni 2001 21:38
To: [EMAIL PROTECTED]
Subject: Re: [PATCH] apr_table WAS: What to do about tables?
Mladen Turk wrote:
[...]
I've treated the apr_table as database table, having columns and
rows
Mladen Turk wrote:
[...]
Based on my really quick reading of your new version of apr_tables.c,
the code looks reasonable. My main worry is that the overhead of
the hash table maintenance, including the function call overhead and
the need to reindex every time the table is expanded, may offset
Mladen Turk wrote:
[...]
I've treated the apr_table as database table, having columns and rows.
When you think of apr_table that way, you can use the same technique
that the databases use to quickly access particular row, using some sort
of indexing.
I like the concept of adding a fast index
As we approach GA for Apache 2.0, the apr_table_t code is
one of the largest remaining performance bottlenecks. I'm
willing to spend some time fixing this, but because there
hasn't been a solid consensus when this issue has come up
in the past, I'd like to get feedback on strategy first.
I can
Brian Pane wrote:
3. Keep using apr_table_t for the fields in request_rec, and redesign
the internals of apr_table_t to support O(log(n)) access
Pros:
* Performance improvement for the httpd
* Almost no impact on code that uses APR
Cons:
* Changes required to
On Sun, Nov 04, 2001 at 03:00:43PM -0800, Brian Pane wrote:
...
2. Change the performance-sensitive fields in the httpd's request_rec
from apr_table_t (like r-headers_in) to some different data type
(e.g., ap_http_headers_t) that supports O(log(n)) or O(1) get/set
operations
13 matches
Mail list logo
