🚀 go-pugleaf

In gnu.epoch.misc Doug Hahn <hahn@sunshine.labs.tek.com> wrote:
> 
> I think the speed must depend on the style of use.  I've found on my
> sparc 2 that when using one screen per buffer, once I've gotten 6+
> buffer/screens, lemacs gets unacceptably slow when switching screens,
> to the point where it takes several seconds for a screen to raise.

There were serious memory leaks in the screen creation/deletion code in 
lemacs releases before 19.4.  Screen management should be much better now.
Screens still take up a lot of memory, and this will be fixed by the Great
Redisplay Rewrite, but creating and deleting them should no longer cause
uncontrolled growth.  

> I hope that when the epoch/lemacs merge comes about, the "speed" of
> lucid emacs is not held up as the ideal to approach!  

Contributions of code to fix these problems are always welcome, of course...

In gnu.epoch.misc marca@ncsa.uiuc.edu (Marc Andreessen) wrote:
> 
> Part of this is due to Xt overhead.

Not if you link dynamically and have any other Xt programs running.

> Epoch wins big on performance by doing its own graphics/windowing
> directly, I think.

I'm pretty sure Xt is not the reason.  

Remember that Epoch is several years older than Lemacs; lemacs has 
barely been metered or tuned at all.

> How much is that menubar worth?  :-)

To some people, quite a lot.  

Beyond that, using the Xt event loop was a requirement for some of
the Energize features we needed.

	-- Jamie