discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Slow application startup when using a theme


From: Fred Kiefer
Subject: Re: Slow application startup when using a theme
Date: Mon, 09 Jan 2012 16:47:33 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]