1296958 - Visited link coloring is visibly slow after refresh or after going back to page

Status: RESOLVED WORKSFORME

(Toolkit :: Places, defect, P3)

Description

[Adrian Sampaleanu]

Attachment: slowrefresh.gif

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160726073904

Steps to reproduce:

Go to https://www.mail-archive.com/[e-mail] and visit many messages



Actual results:

After many messages have been visited (majority of the messages visible on one page), and coming back to the main page showing the message threads will initially show the color of links as blue (unread) after which Firefox relatively slowly (over 5 seconds) updates the link colors to black (visited). This slow refresh of the link coloring also happens when refreshing the page.


Expected results:

Visited links should show as read (black) instantly (or with hardly noticeable delay).

I only notice a delay on this particular site and it's been happening for the last few months now, IIRC (it used to be OK prior to that). I'm not sure if there was some rework on the site when the problem started or whether it was coincidental with a version change in Firefox.

Comment 1

[Adrian Sampaleanu]

Note that I've been visiting this site for years and so if Firefox takes all of my history into consideration when it renders just the visible page, I can imagine that there would be lots of links to consider. Possibly this is what's causing he rendering slowdown. If this is the case, it would be nice to have a way of specifying the deletion of history for a site only for items older than a certain date.

Comment 2

[Tooru Fujisawa [:arai]]

I cannot reproduce the issue, after opening 30 items on clean profile.
Does the issue happen on safe mode and another clean profile?

If the issue doesn't happen on safe mode, it could be the issue from add-ons.
If the issue happens on safe mode but not on clean profile, your history items may be related.

Comment 3

[Adrian Sampaleanu]

In the developer version of Firefox (with the same add-ons as in the release version I generally use) I can't reproduce this either with a similar number of visited links as you, @Tooru. It very well could be the very large number of pages I've visited on this site over the years. The thing is that I don't want to wipe the complete history as I often go back a month or two to check on older threads and it would be a pain to lose track of what I've already read.

Is there a way to partially delete history for a site? Some XML or other editable file?

Comment 4

[Tooru Fujisawa [:arai]]

have you checked safe mode?
it should be better confirming that this is not add-on related thing first, before touching history.

then, history is stored in places.sqlite file in your profile.

Comment 5

[Adrian Sampaleanu]

Confirming that slow link coloring on refresh happens even in safe mode.

Comment 6

[Adrian Sampaleanu]

If it would help anyone, I could export and attach the site history give the appropriate SQL.

Comment 7

[Tooru Fujisawa [:arai]]

thanks!
Moving to Places component.

Comment 8

[Timur Davletshin]

I can confirm this bug on FF 49.0 (safe mode on).

Comment 9

[Marco Bonardo [:mak]]

The visited query is quite simple, but clearly we need to run one query per url, so if the page has many, it may take a bit more. It shouldn't be that slow though, that makes me think the disk was strangely busy or waiting for something.
Do you have an antivirus and would you mind checking if disabling it temporarily helps?

could you please tell us some more information regarding your profiles:
1. size of places.sqlite in the profile folder
2. does vacuuming the db with this add-on help? https://addons.mozilla.org/en-US/firefox/addon/places-maintenance/
3. attach a log from your about:support
4. system specs (cpu, ram, disk type)

This may just end up being the same as bug 484928. There's a patch there but it had unresolved issues.
There's clearly space for improvement here, but we should first measure whether this is a common problem around.

Comment 10

[Marco Bonardo [:mak]]

Also, once 50 will be released (in a couple weeks) please report if this improves, there's a change there that may improve things a little bit.

Comment 11

[Adrian Sampaleanu]

Attachment: contents of about:support

Comment 12

[Adrian Sampaleanu]

My places.sqlite was 61,440KB before vacuuming, 51,200 after. Slow coloring still happens.

Attached contents of about:support.

Processor	Intel(R) Core(TM) i7 CPU       Q 820  @ 1.73GHz, 1734 Mhz, 4 Core(s), 8 Logical Processor(s)
Installed Physical Memory (RAM)	16.0 GB
Available Physical Memory	9.56 GB
Hitachi GST Travelstar 7K500 HTS725050A9A364 (0A72335) 500GB 7200 RPM 16MB Cache SATA 3.0Gb/s partitioned in 2:

C:
Size	149.18 GB (160,184,229,888 bytes)
Free Space	40.41 GB (43,394,150,400 bytes)

D:
Size	315.66 GB (338,939,604,992 bytes)
Free Space	81.99 GB (88,035,905,536 bytes)

Firefox installed on C:

I'll report on 50, once out.

Comment 13

[Adrian Sampaleanu]

Links seem to be refreshing quickly with 50. I consider this resolved.

Comment 14

[Marco Bonardo [:mak]]

I suspect bug 889561 helped by reducing size of the db and changing the url string search to an integer search + comparison... Hard to be 100% sure, but the result sounds good. marking as WFM cause it's hard to confirm the underlying fix.

bug 484928 will stay open for further improvements.
Feel free to reopen if the issue should come back.