On Wednesday 17 December 2008 01:56, Daniel Cheng wrote: > On Wed, Dec 17, 2008 at 6:54 AM, Matthew Toseland > <toad at amphibian.dyndns.org> wrote: > > [17:48:05] <ESR_> Having used this system in a pretty heavy-duty way now I > > have some observations: > > [17:48:51] <toad_> hmmm? > > [17:48:53] <ESR_> 1. Design of the web interface -- very good. The > > arrangement of the controls is clever and logical. > > [17:49:37] <toad_> hmmm that's an interesting opinion, there are dramatically > > different ones ... > > [17:50:11] <ESR_> I think it's impressive. Drab-looking, but who gives a > > shit? > > [17:50:17] <toad_> well basically it's still too geeky, and not enough > > bundled - it needs to incorporate more functionality (i.e. Freetalk), and > > geek-centric stuff needs to be on submenus > > [17:51:06] <ESR_> Could use more stuff bundled in, I suppose, but it does what > > it does quite well. > > [17:51:15] <toad_> also status messages can still take up a lot of room - we > > should move the bookmark updates to only live on the browse page, n2ntms to > > live on the friends page etc, with a single notification on the homepage > > [17:51:20] <toad_> okay, what's 2. ? > > [17:52:58] <ESR_> 2. Performance efficiency of the tools, awful. My machine > > has been brough to its knees by *two uploads*. I can't imagine what the Java > > could be doing to eat my proocessor this way, but X is very sluggish. > > [17:53:16] <toad_> yeah most likely that's due to running out of memory > > causing constant garbage collection > > [17:53:23] <evanbd> Looking over logs and the docs on the web site... I think > > the problems ESR had / is having may have as much to do with poor and > > outdated documentation. > > [17:53:32] <toad_> that's a common problem, the db4o branch solves it at the > > cost of some more disk i/o > > [17:53:34] <ESR_> sorry, that should have been "*two processes*". > > [17:54:03] <toad_> (and slightly more non-GC CPU usage) > > [17:54:45] <ESR_> evanbd: Well, of course! > > [17:54:48] <toad_> the db4o branch should be merged in the next two months, it > > won't solve every performance problem, but it should solve those related to > > memory usage and excessive garbage collection > > [17:55:18] <toad_> evanbd: imho a well designed UI doesn't need lots of > > documentation, nobody reads the docs until they run into trouble ... > > [17:55:51] <ESR_> toad_: You're right. Documentation is an admission of UI > > design failure. > > [17:56:15] <toad_> so for example it should be possible, and easy, to insert a > > freesite from within the web interface > > [17:56:20] <evanbd> Yes, but for one reason or another Freenet has shown a > > persistent inability to build such a UI. I think this merits consideration > > of either the reason that is happening or alternate fixes. > > [17:56:29] <ESR_> (This is probably my most shicking heresy to a Unix > > audience :-) ) > > [17:56:36] <toad_> ESR_: :) > > [17:56:54] <ESR_> Aaargh,,,can't type. > > [17:57:02] <toad_> evanbd: maybe constant firefighting has something to do > > with it? :| > > [17:57:11] <toad_> evanbd: i should have merged the db4o branch a month ago :| > > [17:57:29] <evanbd> I'm sure it does. I'm not saying those reasons are bad > > reasons, merely that they appear to exist. > > [17:57:59] <flaushy> toad_: i would disagree with the statement about > > documentation, but i do think, that that is a field where community can do a > > charme > > [17:58:09] <ESR_> 3. Props to you guys for being smart and responsive and > > really caring about your code. The quality of the on-channel support here is > > high. > > [17:58:11] <toad_> but we do have some idea of what needs to change, in the > > bug tracker and elsewhere ... ian thinks we may be able to get a (specific) > > sponsor to pay for a GUI redesign, we'll see whether anything happens to that > > [17:58:32] <toad_> ESR_: thanks > > [18:00:41] --> mpp has joined this channel (n=mpp at i538776A4.versanet.de). > > [18:00:46] <ESR_> Your guess about the low memory limit leading to excessive > > GC and VM thrashing seems plausible now I've heard it. > > [18:00:59] <toad_> that's what it's been in the past imho > > [18:01:06] <toad_> not in every case but in many cases > > [18:01:32] <toad_> CPU-intensive stuff runs on low-priority threads, so it > > ought not to have a big impact on responsiveness, although we will push your > > load avg up > > [18:02:20] <ESR_> With 17 uploads done the problems seems to be gone, so I > > think number of simultaneous uploads may be a driver; it's probably not often > > anyone pushes that as hard as I just did. > > [18:02:28] <toad_> yep > > [18:02:38] <toad_> well when they do they've learned to up the memory > > limits :| > > [18:02:39] <DuClare> less segfaulted :( > > [18:03:15] <ESR_> The real question is why you have a memory limit at all. > > You're using a language with GC... > > Talking about GC. I always wonder why we have to free buckets manually. > > When i did the TempBucket finalizer, I log the leak with MINOR, but you think > this is a bug and should be logged as error > (see http://archives.freenetproject.org/message/20081125.165832.9d917f92.pt-BR.html > ) > > The later attempts to fix the bug by freeing manually caused some other bugs.. > (see https://bugs.freenetproject.org/view.php?id=2775 ) > > In fact, after r23847, the leak can be collected by GC. > IMO they don't need any fixing.
GC is unpredictable. Disk space is a scarce resource, it's not acceptable to wait for the finalizers to run before freeing it. A GC will not be run before we throw an IOException due to out of disk space. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20081217/213b91bc/attachment.pgp>
