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. > [18:03:34] <toad_> perhaps ... java always has a memory limit afaik > [18:04:00] <toad_> and GC and swapping go together *REALLY* badly > [18:04:09] <toad_> so it makes a certain amount of sense > [18:04:14] <evanbd> Yes, it does. There's no reason you *couldn't* set it > large, but it might be better not to. > [18:06:13] <ESR_> 4. Recovery from failure conditions is really good, ans > something you don't explain well enough. J. Random user is likely, foer > example, to miss the fact that uploads go in a persistent queue ansd *aren't* > aborted if you kill jsite or close the web interface. > [18:06:37] <toad_> jsite uploads *ARE* aborted if you kill jsite > [18:06:51] <toad_> it's one major deficiency in jsite cos it means it's > impossible to insert huge sites > [18:06:56] <ESR_> I'm sorryt, I was think thaw. > [18:06:59] <toad_> ah > [18:07:05] <ESR_> I weas thinking of thaw. > [18:07:25] <toad_> yeah ... thaw is sort of third party ... it's great but we > don't bundle it cos it's not part of the base UI ... > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
