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

Status: RESOLVED FIXED

(Camino Graveyard :: Toolbars & Menus, defect)

Description

[Chris Lawson (gone)]

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.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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 :-)

Comment 2

[Jasper]

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

[Wevah (Nate Weaver)]

There should be a way to limit the number of history items in the menu.

Comment 4

[Mike Pinkerton (not reading bugmail)]

crap, i guess i'll have to optimize it.

Comment 5

[Mike Pinkerton (not reading bugmail)]

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

[ender.mb]

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.

Comment 7

[Chris Lawson (gone)]

(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

Comment 8

[Simon Fraser [no longer active]]

Taking.

Comment 9

[Simon Fraser [no longer active]]

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.

Comment 10

[Wevah (Nate Weaver)]

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.

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(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

[Jasper]

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

[Mike Nguyen]

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.

Comment 14

[Simon Fraser [no longer active]]

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.