Great work! It's WAY better now. There's still room for improvement 
but we're now talking about optimizing things and not making Trean 
usable. :-)



Thank you very much. This is greatly appreciated. From my point of 
view this issue is resolved.

Is this still a problem with the new UI?

You could use a tree that is created dynamically, and not always 
completely. See the DataTree browser for an example.

I think this is more a scalability issue with Horde_Tree than it is a 
problem with trean.  That many categories is just going to produce a 
lot of html/javascript code.  I don't have any clever ideas on how to 
fix this.  Suggestions?

I realized that but had hoped for not having to count them. :-)



Anyway, there are about 280 categories. Maximum depth is 10.

By number of categories, I mean how many items are in the category 
tree on the left of the page in trean?  That's the part that's 
generating the large html files.

There are about 1600 bookmarks for a single user. Users with less 
bookmarks don't seem to have this problem.



As for the categories: I'm not sure. I can run any SQL statement you 
want to verify the precise numbers, though. (I'm afraid I still don't 
fully understand the Horde datatree.)

When you say there are 1600 bookmarks in the database, do you mean 
that you have 1600 bookmarks as a user, or total among all users?   
Also, how many categories are being viewed?

Only the first level is being shown. I meant the reload when I 
uncollapse a collapsed part of the tree after changing the renderer.

Anyway, the problem is still the same.

This only helps of course if you don't set your preferences to expand 
the whole category tree by default.

Same behaviour as before. Only the tree collapses/uncollapses more 
slowly, of course.

Try setting the tree renderer from 'javascript' to 'html' in 
browse.php, line 42.

Yes. It's the category tree and its attributes. That can be seen in 
the attached logs, too.

Did you actually look at the HTML code what *is* producing so much data?

How about "It's on my todo list". I just haven't had a chance to 
really dig into this, yet.

Anything new about this one? Even if it's just "I'm working on it.".   
Trean in its current state is simply unusable with larger bookmark 
collections.



My users think about starting a revolt. ;-)



Seriously, I need to make a decision about temporarily replacing Trean 
with something else or appeasing people. I've no problem waiting for a 
fix but I need to know *if* there will be one sooner or later.

Ok, I think I know why it transfers so much: Until now I didn't 
realize that even if only part of the category tree is being *shown*, 
it's being completely rebuilt including all its leafs, those not 
shown, too, on virtually any action.



On entering Trean: Would it be possible to build only those parts of 
the tree that are shown? I realize that would mean you would have to 
load other parts dynamically when the user uncollapses new leafs.



On entering a category: I don't really see why the whole category tree 
would have to be rebuilt. What am I missing here?



I've attached a ZIP archive containing two logs of the http streams. 
One for entering Trean, the other for opening a category.

Thanks for your quick response, Ben. I've just tried that. 
Unfortunately, it didn't help:



Startting Trean: "GET /horde/trean/ HTTP/1.1" 200 241005



Entering a category with only one bookmark: "GET 
/horde/trean/browse.php?category_id=1810 HTTP/1.1" 200 236853



So getFavicon doesn't seem to be the culprit. I'm now going to 
temporarily switch from https to http and sniff out what exactly is 
being transferred over the network. That should hopefully help finding 
the problem.

In order to help me narrow this down, can you do the following for me?



In trean/lib/Trean.php, getFavicon() function, line 242, add a line 
containing "return '';"



I noticed that this function is a bit of a bottleneck while I was 
working on the search feature.  Let me know what the results are.

Latest CVS (updated about 2 hours before entering this bug report) but 
the following problem *seems* to have started with the option to start 
Trean with a collapsed category tree.



Opening the the "Browse" view, all categories completely collapsed, 
takes about 80 seconds. There are 1617 bookmarks in the database.

It takes as long to enter any category.



Checking my Apache logs for errors I didn't find any but the amount of 
data transferred when opening Trean or any category is so immense that 
I can only consider it a bug:



1. Opening Trean:

"GET /horde/trean/browse.php HTTP/1.1" 200 238033



2. Entering a category:

"GET /horde/trean/browse.php?category_id=1963 HTTP/1.1" 200 238149



3. Switching directly to another category:

"GET /horde/trean/browse.php?category_id=1780 HTTP/1.1" 200 238628



More than 230kb per request doesn't really sound right.