Imminent PHP shindig patch

[Chris Chabot <ch...@xs4all.nl>]

Hey Guys,

Quick update from my previous post, the proxy service is done and  
functional, and the creation of a cache abstraction and sample (file  
based) implementation are done too, so I feel it's pretty much in a  
solid enough state to be submitted for inclusion (this doesn't mean  
it's done, but as the mantra goes in the open source scene, release  
early, release often, right? :) So expect this tomorrow.

But a quick question for the java version experts: While profiling my  
code-base, i noticed it was spending ~45% of it's time  
jsFeatureLoader's loadFeatures function, specifically in the loadFiles  
part. I've added a quick bit of caching around this logic and hence  
almost doubled the speed it.

Now my question is, have you guys seen the same behavior in the Java  
version?

And if so, it might be worth to think what an acceptable caching  
policy could be, caching xml/js files that can be modified locally is  
a bit tricky on its self, but a doubling of performance sounds mighty  
interesting too ... Anyone have any suggestions how to deal with this?  
I'm currently leaning towards "Cache it for an hour, document it, and  
done"

	-- Chris

Re: Imminent PHP shindig patch

[Kevin Brown <et...@google.com>]

On Thu, Feb 28, 2008 at 3:06 AM, Chris Chabot <ch...@xs4all.nl> wrote:

> Hey Guys,
>
> Quick update from my previous post, the proxy service is done and
> functional, and the creation of a cache abstraction and sample (file
> based) implementation are done too, so I feel it's pretty much in a
> solid enough state to be submitted for inclusion (this doesn't mean
> it's done, but as the mantra goes in the open source scene, release
> early, release often, right? :) So expect this tomorrow.
>
> But a quick question for the java version experts: While profiling my
> code-base, i noticed it was spending ~45% of it's time
> jsFeatureLoader's loadFeatures function, specifically in the loadFiles
> part. I've added a quick bit of caching around this logic and hence
> almost doubled the speed it.


This is a one-time initialization cost for Java. In PHP you should
*definitely* cache it. I'd strongly suggest using APC for this task. I
believe the current version supports direct storage of SimpleXML objects
now, but I'd have to double check CVS to be sure of that.


>
> Now my question is, have you guys seen the same behavior in the Java
> version?
>
> And if so, it might be worth to think what an acceptable caching
> policy could be, caching xml/js files that can be modified locally is
> a bit tricky on its self, but a doubling of performance sounds mighty
> interesting too ... Anyone have any suggestions how to deal with this?
> I'm currently leaning towards "Cache it for an hour, document it, and
> done"


Not worth it. Feature xml should only change when the server is restarted
anyway.


>
>        -- Chris
>



-- 
~Kevin

If you received this email by mistake, please delete it, cancel your mail
account, destroy your hard drive, silence any witnesses, and burn down the
building that you're in.