More than ca. 2000 items in History creates noticeable lag in menu display, command response

RESOLVED FIXED in Camino0.9

Status

Camino Graveyard
Toolbars & Menus
RESOLVED FIXED
13 years ago
13 years ago

People

(Reporter: Chris Lawson (gone), Assigned: Simon Fraser)

Tracking

unspecified
Camino0.9
PowerPC
Mac OS X

Details

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050421 Camino/0.8+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050421 Camino/0.8+

I love the idea of your new addition, Mike, where the Go menu displays full
history, but for those of us who do a lot of browsing and/or keep more than a
week or two of history around, it's in dire need of some optimisation. :)

I have about 10K items in my history, which is set for 60-day expiration.
There's about a four-second delay opening any menu in Camino. It would be
tolerable if it were restricted to the Go menu, but it's not, and it's mildly
irritating. Fortunately, I don't use the menus much, but newbie types will rely
on the menus a lot more and probably won't change the history from its default
of 30 days (IIRC).

Reproducible: Always

Steps to Reproduce:
1. Do enough browsing that you have approximately 2000 or more items in History.
2. Click any menu in a nightly from 4/21 or later.
3. Wait.

Actual Results:  
I waited.

Expected Results:  
Not made me wait.
Confirming this.  

I average about 300 pages a day in history and have 9 days saved (is that the
default?).  It takes about 3 sec for a menu to appear on my G4 1.33GHz.  I'm at
about 2400 entries right now due to a couple of light days this week and the
fact it's Friday already in DC.

I'm also noticing a similar delayed response in display of things like the Prefs
and Open File dialogue (called with respective key shortcuts), though they speed
up a little on future calls.  The delay waiting for menus never improves, though.

I really like the feature, too--ultimately it will save me a lot of time--but
the menu delay is a bit of a drag :-)
URL: n/a
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: More than approx. 2000 items in History creates noticeable lag in menu display → More than ca. 2000 items in History creates noticeable lag in menu display, command response

Comment 2

13 years ago
You know what Mike, it appears that all other menu items are also delayed with
this build! I guess you do need to optimze it first :)

Comment 3

13 years ago
There should be a way to limit the number of history items in the menu.
crap, i guess i'll have to optimize it.
Target Milestone: --- → Camino0.9
fwiw, i've backed this out in nightly builds so that we're back to the session
history until i can make it smarter about when it rebuilds itself.

Comment 6

13 years ago
Oddly, this only seems to happen when you first click on a menu--if you click on
one menu then drag the mouse over the others, they open instantly.
(Reporter)

Comment 7

13 years ago
(In reply to comment #6)
> Oddly, this only seems to happen when you first click on a menu--if you click on
> one menu then drag the mouse over the others, they open instantly.

Yeah. I noticed that too. I suspect Mac OS caches the contents of all the menus
when any one menu is first activated, because this happens as long as Camino is
the front-most app, regardless of whether you click on a Camino menu or
something else (like the Apple menu, the system clock, Airport, etc.).

cl
(Assignee)

Comment 8

13 years ago
Taking.
Assignee: pinkerton → sfraser_bugs
(Assignee)

Comment 9

13 years ago
I checked in a more efficient implementation, which should only lag the first
time you click on a menu. Let's see how slow it is with no item limits, then
impose them if necessary. It will be in the 5/14 build.
Status: NEW → ASSIGNED

Comment 10

13 years ago
It does only lag the first time for me...until I navigate to another page. Then
it lags the first time again...and so on. I'd really like to be able to turn
this off and/or limit the number of pages it shows; I find live-searching in the
History view to be much more usable.
(In reply to comment #10)
> It does only lag the first time for me...until I navigate to another page. Then
> it lags the first time again...and so on. 

I'll confirm that.  The lag is a bit shorter than in the first implementation,
but I've also pared my history down from 10 to 7 days since then....

Comment 12

13 years ago
Te lag is indeed noticably shorter but still exsist when a user has a huge
amount of history showing in the menu. I'd go with Wevah comment that we need to
limit what we show. I see no reason for a user to be able to look for a page
he/she opened more then 3/4 days ago. Any longer ago than that and doing a
search in history is way easier.

Comment 13

13 years ago
Works in 10.3.9, but on my 10.4.1 system I get nothing (I see menu item for each
of the last seven days of history but nothing in those sub-menus). Hitting CMD-Y
to get history works fine. 5/14 build.
(Assignee)

Comment 14

13 years ago
I added a 100-item limit on the history submenus now. If you hit that limit, I
add a "Show More" item to the end that just shows the history. Ideally it should
expand the appropriate category, but that's harder, as the view might not be in
date view.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.