You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@excalibur.apache.org by Sylvain Wallez <sy...@apache.org> on 2005/07/28 15:01:16 UTC
Optimizing SourceResolver.release()
Hi all,
I'd like to propose a small change to the Source contract so that
SourceResolver.release() is far more efficient.
Currently, releasing a Source requires to lookup the SourceFactory in
the selector and calling release(Source) on that class. Now looking
around, I found only _one_ implementation of SourceFactory that
effectively does something useful in it's release() method, which is
Cocoon's SitemapSourceFactory.
All other implementations do _nothing_, leading to a lot of useless
lookups. Considering how much source-intensive Cocoon is, this may be
significant.
To avoid this, I'd like to propose a small change to the
SourceResolver.release() contract: if the Source implements Disposable,
then it's dispose() method is called, and otherwise the factory is
looked up as of today.
We then have to add empty dispose() methods to all source
implementations to benefit from the performance improvement.
How does that sound?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Optimizing SourceResolver.release()
Posted by peter royal <pr...@apache.org>.
On Jul 28, 2005, at 2:01 PM, Sylvain Wallez wrote:
> All other implementations do _nothing_, leading to a lot of useless
> lookups. Considering how much source-intensive Cocoon is, this may
> be significant.
>
> To avoid this, I'd like to propose a small change to the
> SourceResolver.release() contract: if the Source implements
> Disposable, then it's dispose() method is called, and otherwise the
> factory is looked up as of today.
Can you run a test with Cocoon under a profiler to see if making that
optimization provides a measurable difference in real usage?
Just to avoid optimizing where not necessary (since there are
backwards-compatibility issues to deal with)
-pete
--
peter royal
Re: Optimizing SourceResolver.release()
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez schrieb:
> Carsten Ziegeler wrote:
>
>
>>Sylvain Wallez schrieb:
>>
>>
>>
>>>Hi all,
>>>
>>>I'd like to propose a small change to the Source contract so that
>>>SourceResolver.release() is far more efficient.
>>>
>>>Currently, releasing a Source requires to lookup the SourceFactory in
>>>the selector and calling release(Source) on that class. Now looking
>>>around, I found only _one_ implementation of SourceFactory that
>>>effectively does something useful in it's release() method, which is
>>>Cocoon's SitemapSourceFactory.
>>>
>>>All other implementations do _nothing_, leading to a lot of useless
>>>lookups. Considering how much source-intensive Cocoon is, this may be
>>>significant.
>>>
>>>To avoid this, I'd like to propose a small change to the
>>>SourceResolver.release() contract: if the Source implements Disposable,
>>>then it's dispose() method is called, and otherwise the factory is
>>>looked up as of today.
>>>
>>>We then have to add empty dispose() methods to all source
>>>implementations to benefit from the performance improvement.
>>>
>>>How does that sound?
>>>
>>>
>>>
>>
>>Don't know, but I don't like the dependency to Disposable.
>>It would be better if we could keep the interfaces clean from
>>Avalon core interfaces.
>>
>>The early versions of the Source interface had a "release()" method
>>which did exactly what you propose. So perhaps we can add an own
>>interface for this in the o.a.e.source package instead?
>>
>>
>
>
> If we do this, this changes the Source interface, and may lead to more
> compatibility problems with implementations out there.
>
> A solution would be to add a "ReleasableSource" interface that extends
> Source and provides the release() method. That way, we don't add
> dependencies on the framework.
>
That is what I meant :)
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Optimizing SourceResolver.release()
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>Sylvain Wallez schrieb:
>
>
>>Hi all,
>>
>>I'd like to propose a small change to the Source contract so that
>>SourceResolver.release() is far more efficient.
>>
>>Currently, releasing a Source requires to lookup the SourceFactory in
>>the selector and calling release(Source) on that class. Now looking
>>around, I found only _one_ implementation of SourceFactory that
>>effectively does something useful in it's release() method, which is
>>Cocoon's SitemapSourceFactory.
>>
>>All other implementations do _nothing_, leading to a lot of useless
>>lookups. Considering how much source-intensive Cocoon is, this may be
>>significant.
>>
>>To avoid this, I'd like to propose a small change to the
>>SourceResolver.release() contract: if the Source implements Disposable,
>>then it's dispose() method is called, and otherwise the factory is
>>looked up as of today.
>>
>>We then have to add empty dispose() methods to all source
>>implementations to benefit from the performance improvement.
>>
>>How does that sound?
>>
>>
>>
>Don't know, but I don't like the dependency to Disposable.
>It would be better if we could keep the interfaces clean from
>Avalon core interfaces.
>
>The early versions of the Source interface had a "release()" method
>which did exactly what you propose. So perhaps we can add an own
>interface for this in the o.a.e.source package instead?
>
>
If we do this, this changes the Source interface, and may lead to more
compatibility problems with implementations out there.
A solution would be to add a "ReleasableSource" interface that extends
Source and provides the release() method. That way, we don't add
dependencies on the framework.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Optimizing SourceResolver.release()
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez schrieb:
> Hi all,
>
> I'd like to propose a small change to the Source contract so that
> SourceResolver.release() is far more efficient.
>
> Currently, releasing a Source requires to lookup the SourceFactory in
> the selector and calling release(Source) on that class. Now looking
> around, I found only _one_ implementation of SourceFactory that
> effectively does something useful in it's release() method, which is
> Cocoon's SitemapSourceFactory.
>
> All other implementations do _nothing_, leading to a lot of useless
> lookups. Considering how much source-intensive Cocoon is, this may be
> significant.
>
> To avoid this, I'd like to propose a small change to the
> SourceResolver.release() contract: if the Source implements Disposable,
> then it's dispose() method is called, and otherwise the factory is
> looked up as of today.
>
> We then have to add empty dispose() methods to all source
> implementations to benefit from the performance improvement.
>
> How does that sound?
>
Don't know, but I don't like the dependency to Disposable.
It would be better if we could keep the interfaces clean from
Avalon core interfaces.
The early versions of the Source interface had a "release()" method
which did exactly what you propose. So perhaps we can add an own
interface for this in the o.a.e.source package instead?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Optimizing SourceResolver.release()
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>Sylvain Wallez schrieb:
>
>
>
>>Well, it's difficult to do something better than a few hashmap puts and
>>gets, and possibly crawl up the service manager hierarchy. All this to
>>end up calling an empty method...
>>
>>
>>
>What about caching the source factories in the source resolver
>implementation?
>During runtime a service manager and selector do never change, so once
>the source resolver has looked up a factory, it can put it into a map.
>On releasing a source, there is then just one single lookup into a map
>that might contain 8 or 10 different source factories.
>So this way we have only one single lookup into a small map while we
>have an instanceof test with your solution. Actually I would like to go
>the caching way as this just improves the performance without adding
>interfaces that are just there because of possible performance issues.
>
>
Hmm... I wouldn't go that way, as OSGi-based Cocoon blocks may allow to
hot-deploy new blocks providing new SourceFactories...
>As Leo and Peter have suggested, did you do any performance tests so we
>can see what these changes actually bring?
>
>
No. I will do some profiling and come back if this brings significant
improvements. So let's keep it as is for now.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Optimizing SourceResolver.release()
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez schrieb:
>
> Well, it's difficult to do something better than a few hashmap puts and
> gets, and possibly crawl up the service manager hierarchy. All this to
> end up calling an empty method...
>
What about caching the source factories in the source resolver
implementation?
During runtime a service manager and selector do never change, so once
the source resolver has looked up a factory, it can put it into a map.
On releasing a source, there is then just one single lookup into a map
that might contain 8 or 10 different source factories.
So this way we have only one single lookup into a small map while we
have an instanceof test with your solution. Actually I would like to go
the caching way as this just improves the performance without adding
interfaces that are just there because of possible performance issues.
As Leo and Peter have suggested, did you do any performance tests so we
can see what these changes actually bring?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Optimizing SourceResolver.release()
Posted by Sylvain Wallez <sy...@apache.org>.
Leo Simons wrote:
>On 28-07-2005 15:01, "Sylvain Wallez" <sy...@apache.org> wrote:
>
>
>>I'd like to propose a small change to the Source contract so that
>>SourceResolver.release() is far more efficient.
>>
>>Currently, releasing a Source requires to lookup the SourceFactory in
>>the selector and calling release(Source) on that class. Now looking
>>around, I found only _one_ implementation of SourceFactory that
>>effectively does something useful in it's release() method, which is
>>Cocoon's SitemapSourceFactory.
>>
>>All other implementations do _nothing_, leading to a lot of useless
>>lookups. Considering how much source-intensive Cocoon is, this may be
>>significant.
>>
>>To avoid this, I'd like to propose a small change to the
>>SourceResolver.release() contract: if the Source implements Disposable,
>>then it's dispose() method is called, and otherwise the factory is
>>looked up as of today.
>>
>>We then have to add empty dispose() methods to all source
>>implementations to benefit from the performance improvement.
>>
>>How does that sound?
>>
>>
>
>Hmmmmmm...like a backward-incompatible change for both source and binaries.
>
>
Uh? I don't see why. It's an optional interface for Source
implementations. It changes none of the current interfaces, and existing
implementations shoud run unmodified.
>I'd suggest getting some profile data showing this is significant rather
>than working on a "hunch". And even then, I dislike having to break
>interfaces for performance reasons. It seems to make sense to make lookup
>less resource intensive instead :-)
>
>
Well, it's difficult to do something better than a few hashmap puts and
gets, and possibly crawl up the service manager hierarchy. All this to
end up calling an empty method...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Optimizing SourceResolver.release()
Posted by Leo Simons <ma...@leosimons.com>.
On 28-07-2005 15:01, "Sylvain Wallez" <sy...@apache.org> wrote:
> I'd like to propose a small change to the Source contract so that
> SourceResolver.release() is far more efficient.
>
> Currently, releasing a Source requires to lookup the SourceFactory in
> the selector and calling release(Source) on that class. Now looking
> around, I found only _one_ implementation of SourceFactory that
> effectively does something useful in it's release() method, which is
> Cocoon's SitemapSourceFactory.
>
> All other implementations do _nothing_, leading to a lot of useless
> lookups. Considering how much source-intensive Cocoon is, this may be
> significant.
>
> To avoid this, I'd like to propose a small change to the
> SourceResolver.release() contract: if the Source implements Disposable,
> then it's dispose() method is called, and otherwise the factory is
> looked up as of today.
>
> We then have to add empty dispose() methods to all source
> implementations to benefit from the performance improvement.
>
> How does that sound?
Hmmmmmm...like a backward-incompatible change for both source and binaries.
I'd suggest getting some profile data showing this is significant rather
than working on a "hunch". And even then, I dislike having to break
interfaces for performance reasons. It seems to make sense to make lookup
less resource intensive instead :-)
Cheers,
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org