Re: Small patches to previously posted updates from OFBiz

Anthony,

The purpose of the RepositoryContent changes was for one thing: to not load 
the content until it is actually requested. The main reason for this was that 
there is no other way to find out the lastModified time for checking whether 
a cache entry should be refreshed or not.

So, the performance hit came because every time something wanted to see if the 
content was modified it had to get a new content object, which used to read 
in the whole file without needing to in 99% of the cases. 

I left the InputStream and Reader directly attached to the repository for more 
efficient reading. Generally they are only called once anyway, so it's not a 
big deal, AFAIK.

Does that make sense? If you'd like we can modify it so that it doesn't do a 
read until requested, and then it populates the data string and creates a 
reader or input stream to read from there. I actually planned on doing it 
this way originally, but for efficiency purposes and based on how it looks 
like it is being used, I left the stream/reader directly connected.

Actually, if the content is meant to be static and not change between calls 
using a Reader or InputStream to get at it is somewhat confusing.

By the way, things are going well in general with the performance runing. 
Originally our main page, which has about a dozen templates composed together 
and actions for about half of them, took 2.2-3.0 seconds to run on my laptop, 
and now it is down to 0.7 to 1.0 seconds. But, I need to get it down some 
more. 

The big culprit that I see right now is the way the XMLConfiguration object is 
being used. I looked around at it and it appears to be reloaded EVERY time it 
is referenced, ie there is no caching at all on it. The URL is even being 
created every time as it grabs the resource from the class loader. I am 
putting a getResource URL cache in place to help speed it up, but it would be 
nice if JPublish used the file more efficiently.

It looks like most places where it is used it is read using an InputStream, 
which makes caching pretty tough because you don't have the filename, etc. I 
was tempted to write an object that is specifically meant for loading and 
caching and reloading the page def XML files, and then refactor all of the 
places that use XMLConfiguration directly to use that class. 

But, after some additional profiling I found out that JavaScript was causing 
more of a slow down than this, so I tabled the issue for a bit. Now we are 
using BeanShell, which is many times faster than the Rhino JS interpreter, 
and I've hacked together a way to cache parsed BeanShell scripts, to that is 
running pretty well. That alone dropped to the time on our main page from 
around 1.6 seconds to 0.8 seconds. Doubling the overall speed means the 
action running alone is probably over 6 times faster.

Anyway, let me know what you think about the RepositoryContent object and the 
was that XMLConfiguration is being used.

Later,
-David Jones


On Wednesday 05 March 2003 14:07, Anthony Eden wrote:
> David E Jones wrote:
> > Anthony and others,
> >
> > Since sending out the last set of files there are two that I have made
> > small changes to.
> >
> > The RepositoryContent is now a bit more intelligent about handling
> > lastModified times, and should be somewhat faster depending on how the
> > repository is implemented.
>
> I am a bit reluctant to add these changes because they do not really fit
> into the purpose of the RepositoryContent class.  Your implementation
> assumes that a RepositoryContent object is "live" in that it can go back to
> the Repository and ask for updated content, whereas my current
> implementation considers the RepositoryContent to be a snapshot of the
> content at the time it is requested and that you should go back to the
> SiteContext.getContent() method to access a content object.
>
> Let me ask you this: is your new implementation necessary for your system
> so much so that it is worth changing the purpose of the RepositoryContent
> class?  Are you caching the RepositoryContent objects or doing something
> else which requires those objects to be "live"?
>
> > The ScriptAction class now passes the "canonical" path as the source to
> > BSF. This provides a more unique identifier to make is easier to cache
> > and, when debugging, locate the script file you are working with.
>
> I have added your changes for the ScriptAction class, however be aware that
> it will require some pretty hefty changes as I move towards supporting
> unexpanded WARs.  Eventually there will be an ActionContent class which is
> similar to the RepositoryContent class.
>
> Sincerely,
> Anthony Eden
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
> for complex code. Debugging C/C++ programs can leave you feeling lost and
> disoriented. TotalView can help you find your way. Available on major UNIX
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Jpublish-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jpublish-developer



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com