httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+apa...@sunstarsys.com>
Subject Re: [apreq-2] win32 workarounds
Date Sun, 04 May 2003 19:31:23 GMT
Randy Kobes <randy@theoryx5.uwinnipeg.ca> writes:

[...]

> Failed tests in Performance:
> 1) perf_init: apr_hash should win: APR = 13.019 vs 
>    APREQ = 9.013 (microseconds)

That one is a good (unexpected) failure, since lower
times are better.

> 2) perf_get_avg: apreq should win (8): APR = 0.000 vs 
>    APREQ = 1.001 (microseconds)
> 3) perf_get: apr_table_get(Accept-Language) wins: APR = 0.000 vs
>    APREQ = 1.001 (microseconds)
> 
> Maybe it's a problem with timing things in Win32? I'll
> take a closer look ... Actually, I'm glad I got these
> failures, as before they were all passing consistently,
> and I started to worry that there was something wrong :)

The results will vary, especially if your CPU is busy
doing other work.  However, the 0.000 times are suspicious. 
If you're consistently seeing that, either your machine 
is considerably faster than mine (Pentium III 500Mhz),
you're apr compiler (optimization) flags may not be the same 
as your apreq flags, or maybe there's a timing bug in 
apr_time_now() on Win32.

At the moment I'm not too concerned about this issue.
There are bigger fish to fry:  I'll soon (today?) be 
committing some substantial changes to the parser API,
gutting the APREQ struct from apreq_env, and adding 
prefetch code to the filter in mod_apreq.  Lately I've been 
thinking a lot about subrequests, internal-redirects & 
such, so my next commit should have the "correct" behavior 
for those situations.

-- 
Joe Schaefer

Mime
View raw message