[dev] Re: [cvs] commit: horde/config conf.xml framework/Horde/Horde Registry.php

Michael M Slusarz slusarz at mail.curecanti.org
Thu Mar 24 14:20:30 PST 2005


Quoting Michael M Slusarz <slusarz at mail.curecanti.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Michael M Slusarz <slusarz at bigworm.curecanti.org>:
>>>
>>>> Quoting Jan Schneider <jan at horde.org>:
>>>>
>>>>> Zitat von Michael M Slusarz <slusarz at curecanti.org>:
>>>>>
>>>>>> slusarz     2005-03-23 16:32:20 PST
>>>>>>
>>>>>>  Modified files:
>>>>>>    config               conf.xml
>>>>>>    Horde/Horde          Registry.php
>>>>>>  Log:
>>>>>>  Implement session caching of some registry information.  See 
>>>>>> conf.xml ->
>>>>>>  'registry_cache' entry for description of what is cached.
>>>>>
>>>>> Cool, that should give a huge perfomance boost. Unfortunately also a
>>>>> memory boost, but that's another story. Did you do any benchmarks?
>>>>
>>>> Not yet.  And in my haste I forgot to add to the conf.xml description
>>>> that "Additionally, caching of registry information will result in
>>>> slightly larger session sizes".  But disk space is cheap, I/O access
>>>> times generally are not, so I expect there to be a noticeable
>>>> difference (1-2%??), especially for something like the sidebar which
>>>> has to parse multiple configuration files.
>>>
>>> Forget it. I actually was talking about memory, not disk space. But the
>>> data gets loaded into memory anyway, whether you use caching or not, so
>>> that doesn't make a difference. The disk space is negligible.
>>>
>>> I actually expect an even higher performance gain, because when I did
>>> some profiling recently, the registry instantiation was one of the hogs
>>> on light or highly optimized pages.
>>
>> Ah, something I forgot to ask. Shouldn't it be sufficient to check the
>> registry.php mtime once per request to eliminate the disadvantage of
>> not being able to change the registry at runtime?
>
> This could be the next step.  Although I thought doing time requests on
> files is a horrendously slow operation that would make negligible gains
> achieved by skipping loading the file.  Then again, it probably is
> worth it.   Having to do it on config files, though, starts adding back
> to the overhead quite a bit...

Follow-up: What about 3 config options for $conf['registry_cache']: 
None, Yes, and Yes with checking of mtimes?  This might be getting to 
cutesy though - maybe it would be better to just pick a method and 
stick with it instead.

michael

_______________________________________
Michael Slusarz [slusarz at curecanti.org]


More information about the dev mailing list