1015548 - Slow location bar autocomplete since 2.25

Status: RESOLVED WORKSFORME

(SeaMonkey :: Location Bar, defect)

Description

[kmike]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 (Beta/Release)
Build ID: 20140428215651

Steps to reproduce:

Upgraded to 2.25, started to type in the location bar


Actual results:

There has been a delay up to 5-10 seconds before any autocomplete results started to show


Expected results:

Results should be shown immediately as in version 2.24.

More info:
Seamonkey 2.26 still has this issue.

My places.sqlite is 136MB. I compacted it with SQLite manager to 125MB but it didn't help.

There is a discussion about this bug at Mozillazine: http://forums.mozillazine.org/viewtopic.php?f=40&t=2822207

Comment 1

[Philip Chee]

Try SeaMonkey safe-mode: Go Help -> Restart with Add-ons Disabled. Does the delay also occur in SM Safe Mode?

Comment 2

[kmike]

Copying my reply from the abovementioned Mozillazine thread:

    Does restarting in Safe Mode make any difference?
    (Help | Restart with addons disabled)


No.

    Does also disabling Plugins help?
    What Plugins do you have?


Doesn't help. Google Talk Plugin, Shockwave Flash, Google Talk Plugin Video Renderer.

    Does a new Profile react properly?

Yes.

    Does it still react properly if you copy your existing places.sqlite file over into the new Profile (exit SeaMonkey first)?


No, it starts to lag similar to my default profile. My places.sqlite is 136MB.

Comment 3

[BhaaL]

User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1
Build identifier: 20140612174402

I've seen the same behavior here with a measly 50mb places.sqlite. And I was able to somewhat improve speeds by removing entries that I've only visited once:

 $ sqlite3 places.sqlite
 sqlite3> delete from moz_places where visit_count = 1;
 sqlite3> .exit

I had about 60k entries there, but only roughly 5k with visit counts > 1. More or less an arbitrary decision to just drop the visited-once-and-never-gone-back-to pages on my side, but it did bring performance back.

The only odd thing about this is that I started seeing this behavior 2 days ago; and I've certainly upgraded to 2.25.x and (now) 2.26.1 pretty much around the time they came out (or rather: when the auto-updater reminded me of it); and not just a few days ago.
So something must have changed there that only recently showed those issues. Maybe something happened to the part of the code that expires places entries? I for one wouldn't mind if those once-visited pages expire out of the list after, lets say a month or so; while other stay longer/forever.

Comment 4

[kmike]

Appears to be fixed in 2.32