On 9 Jan 2012, at 19:59, Eric Wasylishen wrote: > Hi, > Thanks for the report, Philippe; this is indeed a fairly serious problem. :-( > >> >> That would probably works but what about changing how +imageNamed: >> works ? >> >> When this method is called with a image name lacking an extension (ie >> 'GNUstep' or 'common_arrowLeft'), it tries to find a existing file by >> adding any know extension and calling a NSFileManager method, and this 3 >> times (main bundle, theme bundle and then every Images directory in the >> system). With bitmaps existing only in the system directories this is >> extremely costly as it tries something like 500 paths before the good >> one. (And I know you understand all that, I'm just filling the blanks >> for the others who might be interested, sorry :o) >> >> Couldn't we inverse the thing and check if one of the existing file in >> the directories has an extension known to be an image type ? I mean : >> list the files in the main bundle, look for the ones with a matching >> name (ie 'common_arrowLeft') and then check if the extension is none. >> The list of file in a bundle could also be cached. >> >> Worth trying ? > > That sounds like a good idea. > > Much of the overhead when using Neos is caused by the section of -[GSTheme > activate] which loads all images in the theme. > > Here are some tests: > startup Ink with default theme: 51k syscalls > startup Ink with Neos.theme: 183k syscalls > startup Ink with Neos.theme, with GSTheme.m lines 473 to 539 commented out: > 95k syscalls. > > > Fred, even if we implement image filter services support and move the > ImageMagick support to a service, +[NSImage imageNamed:] would still do just > as much work because it uses [NSImage imageFileTypes], which would include > the types supported by filter services. > > > How about adding caching to NSBundle? It already caches the budle info.plist, > why not the directory listing of the resource directory?
I hacked in some quick/dirty cacheing in NSBundle. Does it make enough difference to be worth doing properly rather than reverting? _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev