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] |
jimb@red-bean.com writes: > > As far as Guile's size is concerned: > > What we're trying to address here is not really a technical issue. > It's more of a psychological one: developers will hesitate to include > Guile in their applications if they feel, on a gut level, that it's > too large. > Actually, I believe the runtime memory consumption of Guile upon startup is a problematic technical issue. It causes the memory consumption of a stock copy of scwm with an empty scwmrc and no Scheme modules loaded to be much larger (1.5 to 2.5 times larger depending on the platform) than the corresponding fvwm2 memory image, when it really shouldn't be, since a general-purpose language should allow for much smaller code size for the primitives and thus not much greater memory usage in the no-config case. Part of this is because we have added a lot of features to scwm that are not in fvwm, but memory image was much bigger even when core code size was smaller (and this will probably happen again when we become even more aggressive about moving things from the core to loadable modules). Now, arguably a 3 or 4 meg window manager image vs. a 1 or 2 meg total usage is not that bad in this day and age, but it pains me to waste memory unnecessarily. It also pains me to see people struggle with an ad-hoc config language because they believe it saves a lot of memory. However, I think the main cause of the problem is boot-9.scm, not libguile. Now, obviously, there are many bits there that the module system depends on and can't be moved out until the Great Module System Rewrite, but I think some stuff can be safely consigned to other modules. Jim, would you accept changes to move some of the code from boot-9, such as accessors and non-polymorphic aliases for the posix and network procedures (I'll ask for confirmation on other apparently unnecessary things) into their own modules? Using Mikael's recent autoload stuff this can be a zero-user-impact change but I think the stuff I exlicitly mentioned is not worthy of such treatment. - Maciej