Ok thanks for the feedback --G 2011/10/26 Lucas Galfaso <[email protected]>
> ... and that it is erased when a fragment is attached. > > > > On Wed, Oct 26, 2011 at 1:46 PM, Felix Meschberger <[email protected]> > wrote: > > Hi, > > > > We just have to make sure that such a cache would be bounded ... > > > > Regards > > Felix > > > > Am 26.10.2011 um 18:25 schrieb Richard S. Hall: > > > >> On 10/26/11 05:02 , Guillaume Sauthier (OW2) wrote: > >>> Hi all > >>> > >>> In one of our project we spotted an intensive usage of > ZipFile.getEntry() > >>> due to Felix trying to access the resource associated with a class when > the > >>> class is not defined yet. As the requested resource is not boot > delegated, > >>> nor imported and neither inside of the bundle, getEntry() returns null > and > >>> Felix continue to follow its classloading algorithm. But trying to > access > >>> the resource is time consumming, and the impact is bigger on > performance > >>> when the same resource is requested for each of our request. > >>> > >>> I agree that we could fix this by being more smart in our usage to > avoid > >>> theses error cases, but do you think it could be valuable for Felix to > keep > >>> a "cache" of failed resource request, so that, next time Felix try to > >>> request the resource from the Bundle's content, we simply avoid this > step > >>> and move forward ? > >>> > >>> I feel that it should be quite easy to implement that behavior, but > before > >>> starting this task, I want to have your feedback. > >>> So WDYT ? > >> > >> Actually, I thought we already implemented something like this, but I > >> didn't see it in the code after a quick perusal. I know for a fact that > >> we at least investigated it at one time, so if it is not in there > >> already, we must have deemed that it didn't make much of a difference. > >> > >> If you want to open an issue and work on it, feel free to work on a > >> patch, but please get some before and after performance numbers to show > >> if it is worth it or not. > >> > >> Thanks. > >> > >> -> richard > >> > >>> > >>> --G > >>> > > > > >
