High resource usage on startup; Chromium stops responding shortly after starting

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install Fauxbar on a snapshot build of Chromium
2. Quit Chromium
3. Start Chromium

What is the expected output? What do you see instead?
I found that from about the second time I started Chromium after installing 
Fauxbar that Chromium was almost unresponsive immediately after it started plus 
there was *VERY* heavy hard drive activity

What version of the product are you using? On what operating system?
Chromium 17.0.927.0 (Developer Build 108343 Linux)
Operation system: Fedora 15 64-bit

Please provide any additional information below.
Since I have other extensions installed I wanted to confirm that the cause of 
this behaviour was in fact Fauxbar so I uninstalled it and sure enough, 
Chromium was again behaving as normal.

Original issue reported on code.google.com by russelld...@gmail.com on 2 Nov 2011 at 9:53

[GoogleCodeExporter]

tl;dr: Possible temporary fix is in the second-to-last paragraph.

Fauxbar occasionally recalculates frecency scores for the top 50 
highest-ranking sites, to ensure their scores are fresh (in case you haven't 
visited them in a while). This currently happens every 2 hours, or when Fauxbar 
starts and sees that it's been more than 2 hours since the last time it did 
this.

To try and prevent things from locking up, there's a 200ms delay between each 
update for the 50 sites, to let Fauxbar display the New Tab page if needed.

But perhaps doing all 50 updates in 1 transaction instead of 50 transactions 
would be better ;)

It shouldn't stop Chromium from responding altogether, though. I will try 
testing this myself, and/or I might give you a test build to try, or I'll 
create an option to recalculate the top scores or not. And/or I could have the 
top scores only be recalculated when the computer becomes idle, rather than at 
startup.

But I'm thinking it's a Chromium dev issue? Regardless, I'll look at this and 
probably make a change to improve how these scores are updated.

As an interim fix to prevent Fauxbar from recalculating the top scores:
Install Fauxbar; let it perform the initial setup and display the 8 blank tiles.
Then, Ctrl+Right-click the page > Inspect element > Console tab.
Type in:
localStorage.lastTopUrlRefresh = 2222222222222;

This sets a date (milliseconds since the epoch) way in the future, so Fauxbar 
won't ever decide to refresh the scores upon startup. If you could please try 
this out and confirm if it solves the lockup issue or not, I'd appreciate it. 
(it'll probably be a couple of days before I get around to looking at this 
myself)

Original comment by fauxbar....@gmail.com on 2 Nov 2011 at 11:42

• Added labels: Version1

[GoogleCodeExporter]

Thanks for the reply and suggestions. I realise that my main problem
may be that I am using a snapshot of Chromium build and not an
"official" release. To check if that's part of the problem I'm going
to test Fauxbar with Google Chrome stable.

With regard to the timing issue, I'll try the suggested fix.

I appreciate your prompt reply and will get back to you when I have
results of my testing.

Original comment by russelld...@gmail.com on 3 Nov 2011 at 12:09

[GoogleCodeExporter]

I have made the suggested changes on 2 PCs running the same
configuration and will wait and see what results I get.

Original comment by russelld...@gmail.com on 3 Nov 2011 at 2:22

[GoogleCodeExporter]

For the moment I have switched the two PCs in question to Google Chrome stable 
because when I tried to open the Fauxbar options dialog on the Chromium 
snapshots I was using, Chromium crashed. Things look to be stable on Google 
Chrome so I expect it was a problem with the snapshot, not Fauxbar at all.

I think it would be a good idea, though, to perform the 50 updates (mentioned 
above) in one transaction instead of 50 individual transactions.

Original comment by russelld...@gmail.com on 3 Nov 2011 at 3:29

[GoogleCodeExporter]

Cool, thanks for the information.

As recalculating the top 50 scores really isn't super important, I think I'll 
have it recalculate when the computer becomes idle, rather than at start up. 
And in 1 transaction, yes, haha.

Ideally, all the scores should be recalculated - but I don't want to hinder the 
computer's performance out of the blue (like if video playback stuttering might 
occur). I'll have to do some testing to ensure a high load of calculations and 
updates doesn't bog down Chrome. But then if you want to use Fauxbar in the 
middle of a big transaction, things aren't usable until the transaction is 
done. And always having to check to see if the computer is no longer idle in 
the thick of it all just adds to the resource usage... but I'll see what I can 
do.

Either way, not doing calculations at startup sounds good :)

Original comment by fauxbar....@gmail.com on 3 Nov 2011 at 3:58

• Changed title: High resource usage on startup; Chromium stops responding shortly after starting
• Changed state: Accepted

[GoogleCodeExporter]

For v1.2.0 just released, I've disabled this calculation for now. I will 
address this issue properly in a future update.

Original comment by fauxbar....@gmail.com on 12 Nov 2011 at 4:03

[GoogleCodeExporter]

Issue 72 has been merged into this issue.

Original comment by fauxbar....@gmail.com on 19 Nov 2011 at 2:34

[GoogleCodeExporter]

So disabling the calculation mentioned previously does not seem to have fixed 
this unusable Chrome startup issue (as reported in issue #72). (I've re-opened 
issue #15 for reinstating these frecency calculations.)

However, I'm unable to reproduce this resource-hogging issue on Chrome Canary 
17.0.943.0 on Win7 x64.

I've had a play with adding delays to Fauxbar's background page's scripts being 
loaded, but that caused other crashing issues in Chrome 17, yet had no problems 
on Chrome 15. (On another matter with Chrome 17, Fauxbar seems to crash for me 
just after completing the initial indexing setup, yet is fine on 15 and 16.)

I'm still thinking this is just a Chrome Dev issue. Fauxbar seems fine on both 
Chrome 15 Stable and Chrome 16 Beta (for me...).

Could you (bielejewski.michal, or anyone else with this issue) see if this 
issue happens on Chrome 15 and 16?

Once Chrome 17 becomes Beta, I would love to hear if Fauxbar still acts 
problematic. But since I can't reproduce this myself, makes it hard to debug. I 
don't see any "while" loops in my code that might be causing this.

If you wanted to try, you could enable logging for Chrome: 
http://dev.chromium.org/for-testers/enable-logging
Then install Fauxbar, reproduce the error, kill Chrome, and then take a look at 
the log? (search the log file for "hibkhcnpkakjniplpfblaoikiggkopka" - or email 
the log to me)

Original comment by fauxbar....@gmail.com on 19 Nov 2011 at 4:04

• Added labels: Chrome17

[GoogleCodeExporter]

I'm not seeing this issue occur anymore so I believe it can be closed.

Original comment by russelld...@gmail.com on 30 Nov 2011 at 10:14

[GoogleCodeExporter]

Cool, glad to hear. I assume the Chromium team must've fixed something.

Original comment by fauxbar....@gmail.com on 1 Dec 2011 at 4:23

• Changed state: Fixed