>> Again, I am not going to point the finger against something in particular. >> I would like that major attention be paid to the increasead bloat with >> respect to the benefits that come from a particular feature. >> >> As it is clear that I was against the export in thread/qprocess features, >> I will take this as an example. When I export or preview something in LyX, >> I simply wait (only for some seconds!) the end of the operation. So, the
> Although this is often so, it is not always the case. I've been > working with moderately small documents, but compile times could range > from half a minute to couple of minutes. Throw in beamer slides and > Sweave, and you can get stuck for some time in front of the screen. My experience is similar. WIth small documents, waiting is not a problem. However, for larger documents, asynchronous export is a *must have feature*. Please let me have a word with whoever considers it bloat, and I will do my best to convince them otherwise. The book I've been working on takes nearly 15 minutes to compile. If I had to wait for the entire thing to compile every time I wanted to take look, I wouldn't make any progress. With asynchronous export, though, I simply start the job and get back to work. When the PDF pops up 15 minutes later, I can check the detail I wanted to see, and then dive back into the text. The ability to keep working is worth any amount of "bloat." But even then, I've never seen RAM usage go much higher than 400 or 500 MB or so. (This is in a book with thousands of images.) When finished, it almost always drops back down to 30 MB. So while I agree that LyX should remain as lean as possible, I think this is an artificial constraint. It's silly to limit LyX it to the RAM and CPU limitations 2000 era computers.
