This is the mail archive of the guile@cygnus.com mailing list for the guile project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Greg Harvey <Greg.Harvey@thezone.net> writes: > Mikael Djurfeldt <mdj@nada.kth.se> writes: > > > Should I really need to do all dynamic GUI stuff in C code? > > Definately not. But, is it going to be generating that much garbage > that the gc will be invoked so many times as to slow the thing down > noticably?> > [...] > This is a desire for very short, unnoticable pauses, and that's the > goal anyway. If I can't notice the GC pauses in the behaviour of the GUI, then *I'm* happy (although I can imagine that better-than-human realtime performance could be wished by other types of applications). But I have one additional wish (I haven't yet had time to read your text, so I don't know if you address this problem): When Guile switches to real threading (POSIX threads) we'll have to stop all threads, using mutices, before GC with the current collector. > > May I ask: How important is *performance* in a scripting language? > > Important, but not the most vital bit in most uses. The main benefit > to a scripting language is the programming time it saves. > [...] Exactly. This is what I meant when I wrote the question. (But it seems to me that both you and thi interpreted it differently. The last lines of my letter was supposed to mean: Slowing down Guile a little may be worth the cost if it makes Guile useful for new classes of tasks, like those dependent upon realtime performance.) > It doesn't matter to me whether it takes 5 ms or 5 seconds to start > up (This is really a different issue than the one we discuss above.) I don't agree. While performance may not be the most important thing in a scripting language it is extremely important that it doesn't take 5 s to start up. I want to write Guile scripts to use as tools from the command line. That kind of scripts has do startup swiftly. I would get crazy if commands like `ls' and `cd' took 5 s to start. Many of my bourne shell scripts are tools on the same level. An example of the kind of scripts I'm referring to is a "module" command which I've written in Guile. I use it to switch between different versions of packages by altering environment variables like PATH, LD_LIBRARY_PATH etc. But I don't think we have to worry much longer about start up time in Guile. Gary is rewriting I/O---that will be a big boost. Eventually, when we get the new module system and have had time to do a bit of restructuring, startup time will be acceptable. /mdj