You should really consider adding a ;tldr section in your posts ... 2011/4/1 Ken Wesson <kwess...@gmail.com>
> (I'm aware that there's a separate Enclojure Google Group but it seems > to get very little traffic, and I've seen similar issues to mine > raised there for literally years without seeing an answer posted > there, so I'm asking here.) > > While Enclojure provides a decent REPL and generally decent editing UI > and project management, it has one serious Achilles heel for me (aside > from lack of rainbow parens): > > It gets hung up from time to time. > > Though I haven't known it to wedge and stay that way, necessitating a > sigkill/task manager intervention and restart, if it's been left alone > for any length of time, I often find it hung and nonresponsive when I > come back to it. It often seems normal until I click in either the > REPL or an edit pane and then goes to a busy cursor; regardless, it > will usually be from one to three MINUTES before I get a blinking > cursor. > > And then, if I actually type something at it, it freezes again for > several MORE minutes. > > If I then make a REPL, it will typically freeze again for several MORE > minutes. > > Once all three of these freezes have been endured, it tends to stay > usable as long as it's not backgrounded for too long. > > Now, to my understanding, software is not like electric motors and > machinery with moving parts. It doesn't get gummed up and balky until > you get the machine oil that lubricates its parts warmed up again. > > That considered, Enclojure does a surprisingly good emulation of being > a balky mechanical contraption at times. > > An interesting question is, of course, what is it actually *doing* > when it's not responding, as a UI-dominated tool should, to user > input? The Windows task manager offers a possible clue: the netbeans > process will be using no detectable CPU but its process size will be > growing rapidly, packing on several megs every second, typically > bloating up to several hundred megs by the time it gets out of the > third and final freeze. > > So, apparently it is allocating memory and building some very large > data structures. And the time it takes and low CPU use suggests it's > populating those data structures with data it gets from the filesystem > rather than by computing. > > The second clue is that there will be a status indicator during the > first freeze, at least, that says "Checking for external changes"; it > rapidly reaches 99% and then hangs there for the duration of that > freeze. So it may even be network I/O that it's waiting for, network > I/O that's timing out instead of connecting. > > The data structures don't appear to be temporary; the NB process size > stays that huge for as long as it's in use. If it's backgrounded for a > while (not sure exactly how long) the extra memory use disappears > again. > > Since as far as I am aware most or all of NB is implemented in Java, > the pattern of large, expensively-created data structures lingering > but eventually vanishing during idle time suggests SoftReferences hold > those data structures. As for what they are -- maybe all the > information needed to quickly autocomplete, pull up JavaDocs, and > things like that? If so, it could be a general issue with NetBeans > that's more the fault of the sheer size of Java's standard library > (and thus all the declarations and documentation URLs and such) than > anything else. > > Still, it is, IMO, poor design for NB (or, if it is that, Enclojure) > to lock the user out of using the application while it regenerates > these data structures. Having autocomplete and doc lookup be chancy > for a little while (or cause a Please Wait... dialog with a cancel > option) while the data structures are generated in the background > would help. Also, if it is using the network, or groveling over all > sorts of jars and subdirectories, or both, perhaps it should cache a > serialized representation of those data structures on disk, even > across sessions. > > At the *very* least, IMO, there should be a modal dialog if the app is > going to be unresponsive and not just a note in the status line; its > message should be less cryptic than "Checking for external changes"; > and the progress meter should be "honest" rather than jumping to 99% > almost instantly and then sitting there for minutes. > > In any event, I'm not calling this an Enclojure bug or even a NetBeans > bug just yet. It's a wart, at minimum, and it may be in NB rather than > specific to Enclojure. > > But I am asking if anybody knows more about this, and especially if > anybody knows of a way to grease the wheels, so to speak, or to keep > them well lubricated during idle periods. > > FWIW, the machine is fast, has fast disks, has broadband, and has 3GB > of RAM, of which typically no more than 2 are in use at any given time > (so thrashing should not be a concern). NB should not have any > problems with network access (even non-HTTP, unless it's opening a > listen socket to receive from remote Internet hosts) caused by > anything between itself and my ISP. Disks shouldn't be too fragmented; > on the other hand, the installed docs and other materials may > sometimes take the form of many small files rather than jar files, > which might act the same as fragmentation. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
