Re: The New GNUstep Seems Slow

[David Chisnall]

Also check for problems with the pasteboard and distributed notification 
daemons.  I've had a few problems recently with GNUstep apps seeming very slow, 
due to the daemons not starting, or communications problems.  Starting them 
manually and (in one case) deleting the GNUstepSecure directory used to store 
the points made the problems go away.

I think there might be a bug in NSConnection somewhere, but whenever I look for 
it I stop experiencing problems...

David

On 28 Apr 2011, at 18:16, Eric Wasylishen wrote:

> I'd suggest trying kcachegrind (nice gui profiler from what I recall) or 
> gprof.
> 
> For gprof you have to do a 'make clean' of everything then 'make profile=yes' 
> - I think kcachegrind works on unmodified builds.
> 
> I'll give these a try when I have a chance - sometime GS feels a bit slow for 
> me too.
> 
> Eric
> 
> On 2011-04-28, at 4:08 AM, Fred Kiefr wrote:
> 
>> I don't know about any specific reason why GNUstep should now be slower. 
>> This seems to be an important issue to investigate. Which bacend are you 
>> using? A wrong backend is the most common reason for a slowdown. If this 
>> isn't the case we need to use tools to find out where the time gets spend. I 
>> will send a mail on this next week, when I am back home.
>> 
>> Fred
>> 
>> On the road
>> 
>> Am 27.04.2011 um 07:07 schrieb Germán Arias <german@xelalug.org>:
>> 
>>> Yes, I noticed too that the new GNUstep is a bit slow. But not too. On
>>> my machine, GWorkspace works fine and fast. So your problem should be
>>> something with configuration or installation.
>>> 
>>> 
>>> On mar, 2011-04-26 at 18:12 +0100, Richard Stonehouse wrote:
>>>> GNUstep built from the recent tarballs:
>>>> 
>>>>  gnustep-make-2.6.0
>>>>  gnustep-base-1.22.0
>>>>  gnustep-gui-0.20.0
>>>>  gnustep-back-0.20.0
>>>> 
>>>> runs but seems very slow. On launching GWorkspace, it takes approx
>>>> 30 - 35 secs before a blank window appears, and a further 10 - 15
>>>> secs before this gets filled in with the file browser display. During
>>>> the whole of this time GWorkspace is taking nearly 100% of the CPU. In
>>>> the previous version (make-2.4.0, base-1.20.1, gui- and back-0.18.0)
>>>> the whole sequence used to take just 2 - 3 secs.
>>>> 
>>>> Other operations in GWorkspace, e.g. moving to an adjacent column in
>>>> the display, are also slow and CPU-intensive. Other applications,
>>>> e.g. SystemPreferences, show similar but less extreme symptoms.
>>>> 
>>>> It may well be that I've made an error in the build, but the only
>>>> obviously suspicious thing is a message in the gnustep-base build
>>>> output:
>>>> 
>>>>  "gnustep-base-1.22.0-1130.1-results.txt:checking for thread-safe
>>>>  +initialize in runtime... configure: WARNING: Your ObjectiveC
>>>>  runtime does not support thread-safe class initialisation.  Please
>>>>  use a different runtime if you intend to use threads."
>>>> 
>>>> The machine is single-processor and the Objective C library is
>>>> 
>>>>  libobjc45-4.5.0_20100604
>>>> 
>>>> from the openSUSE 11.3 distribution.
>>>> 
>>>> Is this a known problem? (I seem to remember some discussion of
>>>> diagnostic code slowing things down but assume this has been removed
>>>> in the tarball release).
>>>> 
>>>> If not, what further diagnostics would be useful?
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Discuss-gnustep mailing list
>>> Discuss-gnustep@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
>> 
>> _______________________________________________
>> Discuss-gnustep mailing list
>> Discuss-gnustep@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
> 
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep


-- Sent from my Apple II