... and that it is erased when a fragment is attached.
On Wed, Oct 26, 2011 at 1:46 PM, Felix Meschberger <fmesc...@adobe.com> 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 >>> > >
