FWIW, I see two stats rather than three to fetch c:/website/file500.html (an improvement).
The first is: core_translate() apr_filepath_merge() apr_stat() The second is: core_map_to_storage() apr_lstat() apr_stat() Haven't dug into the code but is there a safe way to eliminate the filepath_merge or is this something required on Windows (in which case perhaps the results can be cached). Bill ----- Original Message ----- From: "William A. Rowe, Jr." <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, November 09, 2001 11:30 AM Subject: Re: cvs commit: httpd-2.0/server request.c > From: "Greg Ames" <[EMAIL PROTECTED]> > Sent: Friday, November 09, 2001 10:15 AM > > > > [EMAIL PROTECTED] wrote: > > > > > > wrowe 01/11/09 00:08:43 > > > > > > Modified: server request.c > > > Log: > > > Reintroduce the 'one stat dir_walk' > > > > Bill, > > > > How confident are you that this is rock solid? i.e., should I consider > > bumping it into 2.0.28? It would be great if we could have the > > performance benefit, but IMO stability is the top priority for a beta > > candidate tarball. > > Agreed that stability is key - and this is optimization, not essential. > > However, I don't mind incorporating it into .28. > > > Bill S. said he'd test it on Win32. I can test it on Linux and FreeBSD. > > Please, do. Then let's draw it up for a few hours on apache.org to really > pound on it. > > It is entirely possible this introduces a hole, but I doubt it. I see about > five cases that it could cause trouble... then I rewalk the code and realize > that they are already protected against. Thinks like skipping the final stat, > well, we already glom the final stat outside of that loop. > > Come to think of it, the only scenario I can picture is; > > user requests a symlink (the final filename component) > we stat -> optimize > the loop gets down to that last element/symlink > we optimize away the actual stat to the target file > > That's badness, but it's the only scenario I can picture. What if we take > it a step further, and test 'is this the end?' before we go and skip that > last lstat. In this case, we can skip the lstat, but we musn't skip the > actual stat. > > Stat'ing the final target, rather than lstat'ing it, is no good, we would end > up with a stat - lstat - stat sequence that is a waste. > > Bill > > >
