271016 - Slow performance when deleting multiple items from the History sidebar in "By Last Visited" view

Status: RESOLVED WORKSFORME

(Core Graveyard :: History: Global, defect, P4)

Description

[Rich Parker]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

I like to see a flat view of my history items, sorted by the date/time I last
visited.  I miss Mozilla's full-window history view with URLs and the date/time
for each, but that's another story.  When I choose multiple items from the "By
Last Visited" view and delete, the deletion takes much longer than it should.

Reproducible: Always
Steps to Reproduce:
1. Open the History sidebar.
2. Click the "View" drop-down and choose "By Last Visited".
3. Click the area to the left of the first item to select it.
4. Hold Shift and click 20+ items down to select many at once.
5. Press Delete.

Actual Results:  
Firefox takes 4 - 5 seconds to delete 20 history items on a 1.8 GHz machine.

Expected Results:  
It should happen much faster.  Mozilla 1.7 deletes 50+ history items in a
fraction of a second.

Comment 1

[Rich Parker]

I've seen a few open bugs about performance problems with very large histories,
but mine is set to just 14 days and history.dat is less than 1.5 MB.

Comment 2

[jag (Peter Annema)]

I'm seeing this with 1.8a5 on Mac. Judging by the sound my harddisk is making, the histsory DB is 
written to for every item removed.

Comment 3

[Sander]

I can confirm jag's comment, simply by having looked at my profile in explorer
and refreshing, seeing my 24MB history written out dozens of times.

Comment 4

[Mike Connor [:mconnor]]

Hmm, we had something similar in cookies, and mvl added a timer to write changes
to disk after like 2 seconds of inactivity, so that we could delete as a batch.
 We probably need something along the same lines here, as a stopgap until
mozStorage replaces mork.

Comment 5

[[e-mail]]

This was caused by the fix to bug 234700.

Comment 6

[[e-mail]]

By my reading of the code the file should get flushed after the deletions so I
guess that's where the commit type should have been fixed.

Oh, and as that patch has gone on all the branches then any fix to this bug will
have to get approval too...

Comment 7

[Tim Connors]

(In reply to comment #6)
> By my reading of the code the file should get flushed after the deletions so I
> guess that's where the commit type should have been fixed.
> 
> Oh, and as that patch has gone on all the branches then any fix to this bug will
> have to get approval too...

Is there any status on this bug?

It surprises me that it takes more than 10 minutes (I clicked "cancel" when the
"this javascipt seems to be stuck in a loop; do you want to kill it" popup came
up for the second time) simply to delete a few hundred (perhaps thousand)
entries from a history file.  Computers are meant to be good at handling lists!

If it helps (it seems you already know what's wrong), an strace reveals that it
is in a constant loop of doing things like:

_llseek(33, 5521408, [5521408], SEEK_SET) = 0
write(33, "1)\n    (^87=)]\n  [1B61F(^82^60F6"..., 16384) = 16384
_llseek(33, 5537792, [5537792], SEEK_SET) = 0
write(33, "1121)(^83^5E8B7)(^88^2E3CA)(^89="..., 4096) = 4096
write(33, ")(^84^6118D)(^85^6118D)(^83^610B"..., 1857) = 1857
close(33)                               = 0
munmap(0x405d4000, 4096)                = 0
open("/home/ssi/tconnors/.mozilla/firefox/5h3z6i33.default/history.dat",
O_RDWR|O_CREAT|O_TRUNC, 0666) = 33
fstat64(33, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x405d4000
_llseek(33, 0, [0], SEEK_SET)           = 0
write(33, "// <!-- <mdb:mork:z v=\"1.4\"/> --"..., 16384) = 16384
_llseek(33, 16384, [16384], SEEK_SET)   = 0
write(33, "89)(49391\n    =1123822883320662)"..., 16384) = 16384
_llseek(33, 32768, [32768], SEEK_SET)   = 0
write(33, "\nlat=0&long=0&rand=2011&status=b"..., 16384) = 16384
_llseek(33, 49152, [49152], SEEK_SET)   = 0
write(33, "\n    =http://mail.google.com/mai"..., 16384) = 16384
_llseek(33, 65536, [65536], SEEK_SET)   = 0
write(33, "f84&auto=1&zx=cj9lqr3kwred)(54DB"..., 16384) = 16384
_llseek(33, 81920, [81920], SEEK_SET)   = 0
write(33, "view=tl&search=inbox&start=0&\\\nt"..., 16384) = 16384
_llseek(33, 98304, [98304], SEEK_SET)   = 0
write(33, "0)(55058\n    =http://mail.google"..., 16384) = 16384
_llseek(33, 114688, [114688], SEEK_SET) = 0
...

The loops stays the same for minutes on end,  and then when I check back, it
occasionally switches over to a different set of URLs.

Comment 8

[Tim Connors]

(In reply to comment #7)
> Is there any status on this bug?
> 
> It surprises me that it takes more than 10 minutes (I clicked "cancel" when the
> "this javascipt seems to be stuck in a loop; do you want to kill it" popup came
> up for the second time) simply to delete a few hundred (perhaps thousand)
> entries from a history file.

Note that the reason why this bug pops up in the first place, is because simply
/adding/ an entry to the history list (ie, opening a web page), now takes 2
seconds on my dual P4.  Sure, I keep my history around for 21 days, but adding
to a list should *never* be anything more than O(logN) at the most, and ideally
linear O(1).

Comment 9

[Rich Parker]

Not sure what happened to this, but I tried it again in FF 2.0 and there's no longer a problem.  I deleted 25 history items almost instantly.  I don't think I tried it with 1.5.  Okay to close the bug?

Comment 10

[Jesse Ruderman]

Marking as WFM per comment 9.  See also bug 402486, a similar issue on trunk (where Seth Spitzer is working on a patch).