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 <[email protected]>: > >> 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 >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnustep > > _______________________________________________ > Discuss-gnustep mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnustep _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
