On 09.01.2012 15:00, Philippe Roussel wrote:
Le lundi 09 janvier 2012 à 14:17 +0100, Fred Kiefer a écrit :
On 09.01.2012 00:58, Philippe Roussel wrote:
Hi,
I just noticed that applications start a lot slower when using a non
default theme like Neos.
To test this I added a NSLog as the first line of the AppController
-init method and this is what I get (with a hacky method).
With GNUstep theme :
philou@woody:~/sources/SimpleAgenda$ date +%X.%N&&
./SimpleAgenda.app/SimpleAgenda
22:56:17.054406845
2012-01-08 22:56:17.826 SimpleAgenda[14542] AppController -init
With Neos theme :
philou@woody:~/sources/SimpleAgenda$ date +%X.%N&&
./SimpleAgenda.app/SimpleAgenda
23:01:01.740665917
2012-01-08 23:01:05.015 SimpleAgenda[14643] AppController -init
This is almost 3 seconds slower and easily reproducible :(
When I apply the following patch, application startup is under 0.5
second, no matter what theme I choose.
--- Source/NSImage.m (révision 34462)
+++ Source/NSImage.m (copie de travail)
@@ -1812,6 +1812,7 @@
+ (NSArray *) imageFileTypes
{
+ return [NSArray arrayWithObjects:@"tif", @"tiff", @"png", @"gif",
@"jpeg", @"jpg", nil];
return iterate_reps_for_types([NSImageRep registeredImageRepClasses],
@selector(imageFileTypes));
}
Hard coding the file types isn't an option her, what we could do is
cache the file types in the four relevant methods and make sure we clear
up the cache each time a new NSImageRep subclass gets added or removed.
I will try to implement that and you should then measure the time
difference.
Fred, I know hard coding is not a solution, this was just a simple way
to reduce the number of file types. Caching will not improve speed (I
tried it after my email), the problem comes from the code in NSImage
+imageNamed and the number of file types. Look at the attached file in
my previous mail, you will see that +imageNamed is looking for the file
at hundreds of places (number of paths * number of file types).
Thank you for the explanation, now I understand the issue. It is the
GSImageMagickImageRep class that is causing the trouble. It offers
almost 200 hundred image formats and that makes image lookup very slow.
The real solution here would be to turn this class into a conversion
filter and rewrite the image lookup to first check for unfiltered image
types and only later for the filtered ones.
We already have an example on how to write such a service in
devmodules/usr-apps/examples/gui/ExampleService/. Maybe during FOSDEM
Richard finds the time to pass on the filter service lore to me.
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
