* Brian Akins <[EMAIL PROTECTED]> wrote: > Any thought into parsing the results of the includes filter (offsets, > etc.). In our environment, parsing the includes files is a huge > performance hit.
Just some thoughts from top of my head: I'd say, if we do, only with the new code. The old one is not very applicable for such a task. However, it sounds interesting. First we must define the cache keys. Cache by URL? By file? by ETag? What about dynamic resources? The second point is, that caching in a performant manner probably only should occur on per child basis (like rewrite map caching). This is highly useful in multithreaded environments, of course. The third point is, that there's no real parse tree;-) We just skim through the document and remember only the necessary things (FLAG_PRINTING etc.). We'd need to remember what when happend, i.e. need to build a (kind of) parse tree for exactly this purpose. (Array of "tokens" as a first thought). But there's still the question whether this really saves performance. This depends on how fast the actual bucket stuff around is (compared to the parsing code). We still must read the buckets and pass them through at minimum. Last but not least; it would be quite interesting to create just an abstract API for this in mod_include and build another module that does the actual caching. I'm not sure whether this make really sense, however ;) Further thoughts if I have more time ... nd
