Martin Stjernholm wrote:
>"Stephen R. van den Berg" <<srb[at]cuci.nl>> wrote:
>It'd be fairly simple to add p-code caching to rxmlparse.pike as well
>(actually got a half-baked patch for that).
I'd be interested in seeing that one.
>> I see. Well, I never run without thread support... Except, when running
>> under gdb. Debugging a threaded program still is more painful than
>> debugging a single threaded one.
>Is it? I've never felt bothered by it (unless, of course, it's a
>thread problem I'm trying to debug). So you have a pike compiled with
>--without-threads for debugging?
Well, I create a Pike like that when the going gets tough. Not very
frequently, but it is nice to be able to when it is necessary.
>> So in order to simplify debugging I'd wish the no-threading support
>> to not completely die; /.../
>Well, if your patches are what's required for that then it's ok. But
>they need a bit of cleanup first.
AFAICS, they are just what the doctor ordered. In which way do they
need cleaning?
>> The reasons it would be good to do it the new way is are:
>> a. It would save a *lot* of cycles in the hottest path, as long as you match
>> exact.
>I doubt it's a _lot_ of cycles, but it's some. If one's into that, I
>guess a bit more could be shaved off by splitting the matching so that
>the host is matched separately from the path (which I believe almost
>never is a pattern).
>And it is afterall possible to retain the order even with this: Just
>keep a flag for every entry to tell whether it's a glob or not. (Not
>that it'd necessarily be an unbending requirement to keep compat here,
>though.)
I'll review the code again, and optimise it a bit more (if that turns
out to be possible).
>I've several times got a bit hampered by the general all-or-nothing
>approach in git. E.g. a working tree has to be completely clean to
>switch branches (while cvs just patches the changes over into the new
Git supports that, normally, I do it regularly. It refuses when
it fails to find a common ancestor though (might be a result of the
not yet completely perfect Roxen import into git).
>Anyway, this is currently a non-issue for us, and implementing a
>directory move would make it one. 5.0 is long overdue and we are
>actually working hard to push it out the door, so we're not looking
>for more trouble right now. Sorry.
I see. No problem, there are more ways to solve this.
>> /.../ or we fix (a), and make sure that there is (preferably one) a
>> place where the local path can be configured.
>There is some support for a $LOCALDIR "variable" in paths. Maybe it
>just needs to be extended?
I'll look into this.
>> Hmmm...
>> in my CMS, once I find that a certain object has changed, I force all
>> upstream caches which contain (part of) this object to flush and recache.
>> That might be the cause then.
>On-demand invalidation of entries in <cache> tag caches is on the
>wishlist. Are you using timeout tricks to achieve that?
Well, not quite, it signals itself through the modification time of the
template file. The db does a quick check what the most recent object
is it has in its hierarchy. The parsing is only started when the most
recent (partial)object is newer than the previously cached version of the
whole page.
--
Sincerely,
Stephen R. van den Berg.
If there's a hard way to do something, I'm there before anyone else.
|