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] |
Jim Blandy writes: > mdj writes: > > > 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.) I agree with the last sentence. But to me, the word "performance" is unitless and thus meaningless; better to stick w/ established terms: interactive latency and throughput. To restate: reducing Guile's throughput may be worth the cost if it makes Guile useful for new classes of tasks, like those sensitive to interactive latency. > This is the crux of the matter. > > Which would people prefer? > 1) Guile becomes slower overall, but does not pause noticeable for GC. > 2) Guile becomes faster overall, and most GC pauses become > unnoticable, but does still pause occsionally? I would prefer both, if possible, with runtime (or maybe start-time) configuration. For most of my Guile usage, (2) is fine, and perhaps can be made to behave like (1) with some cleverness. However, when I really need (1), it would be nice to have it there. thi