[Top][All Lists]

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

Re: Observations and Issues With Gstep Win32

From: Christopher Armstrong
Subject: Re: Observations and Issues With Gstep Win32
Date: Wed, 24 May 2006 11:47:41 +1000
User-agent: Thunderbird (Windows/20060308)

mcg wrote:
With the help of a graduate student in my lab, we figured out how to get the program to run "standalone". I will try to add this to the Wiki in the future, but basically we: 1. Copied the gnustep-base.dll, libiconv-2.dll, obc.dll to \WINDOWS\system32 2. Created a ".BAT" file with the command line parameters for running the program
3. Double-click the .BAT file to start the program.

So now we are looking into whether the licenses for these libs will allow us to package them up with our program (which is permissive opensource) into a windows installer program. That way, it would be truly standalone. I'll report back how that goes. If anyone else has insight into the licensing, it would be very helpful.
I didn't realise that when you said "application" you meant what is in GNUstep parlance a "tool". These are much better able to be drawn out and run separately from the GNUstep environment, and quite alot of developers do this. gnustep-gui OTOH is much harder. Licencing shouldn't be an issue; GNUstep uses the LPGL for most its libraries. There is quite alot of information about the LPGL on the Internet (perhaps try http://www.gnu.org/licenses/licenses.html#LGPL as a start, although this tends to focus on why people shouldn't use this licence).
I found out a bit more about the speed issues - part of it is memory allocation. Our program does many realloc-type operations using NSMutableData as it loads data from a file. Making this fine-grained on Linux and OSX doesn't seem to impose much performance penalty. However, in Windows, when I changed this to be much coarser-grained (i.e. reallocing much larger amounts at a time), it ran substantially faster. It is still 2-3x slower than Debian on the same machine, but that's an improvement over 10x slower. So, anyway, your ideas about this having to do with heap-checking are probably right. I'll try checking the detailed compile output as you suggest as soon as I get a chance.
I thought it could be memory allocation. I've found as a bit of Windows programmer, extensive memory allocation/reallocation/deallocation can have significant impacts on performance, maybe because these things actually run inside MSVCRT.DLL (perhaps Linux/BSD has better/faster heap managers?). I've certainly found that's the case through experience. Heavy threading might cause slowdowns (although I doubt it), and many other non-native UNIX primitives (like signals, forking etc) are generally pretty slow when emulated on Windows.


reply via email to

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