Re: SFML2 Demo Dilema - Solved
- Posted by ne1uno May 14, 2015
- 2355 views
This may, or may not, be something you can use, but I'll throw it out there for discussion:
SFML looks to be about as complex as GTK3, with lots of stuff to wrap. When I started working on EuGTK, I tried to link all the functions at startup. Not a good idea. Took forever to start up. Since GTK is object-oriented (as is SFML), I thought 'there's no use in linking functions that my program won't ever use', and so I link only the functions (methods) required for a given object that is declared in a program.
IOW, if your program creates a window, then the window methods (and inherited methods) are linked. If your program uses a button - or 100 buttons - the button class methods are linked (once). Not many programs are going to use more than a couple dozen object classes.
Perhaps - or not - the same approach could be used with SFML?
good point. link on first use would not be too difficult to setup. I don't use win32lib much, but, I wonder if this is part of the reason a large win32lib program takes longer to start up? maybe not that much since most of the win32lib demos startup in less than a minute on an underpowered Xp system.
also, if you qualify all the routines in your program startup is faster. since euphoria won't have to search for conflicts quite as much. this kind of thing. stdseq:split()
other things can add to startup time: how many paths will euphoria look at to resolve includes. run procmon or regmon, filemon to get an idea in windows. python has a commandline option to output to console its resolving paths while starting up. euphoria could use something similar.
run eu prog -w file to write out it's warning file some of the stdlib could use some cleanup again.
