(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
