Re: Observations and Issues With Gstep Win32

[Christopher Armstrong]

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.

Regards
Chris