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