starred/floccus

Fork 0

mirror of https://github.com/floccusaddon/floccus.git synced 2026-04-25 22:26:06 +03:00

[GH-ISSUE #65] High CPU usage and long Sync times #66

New issue

Closed

opened 2026-02-25 22:36:01 +03:00 by kerem · 7 comments

kerem commented

2026-02-25 22:36:01 +03:00

Owner

Originally created by @arendtio on GitHub (Mar 30, 2018).
Original GitHub issue: https://github.com/floccusaddon/floccus/issues/65

Software versions

Browser: Firefox 59.0.1
Nextcloud: 13.0.1
Nextcloud Bookmarks app: 0.11.0
Floccus: 2.0.2

Steps to reproduce

Nothing special.

Initially all bookmarks are synced (about 300 Bookmarks, (very few folders, maybe none))
Trigger the sync manually or let Floccus sync automatically

Expected outcome

Without any changes to the bookmarks a sync should be done within a second (max 3 seconds).

Actual outcome

Every time Floccus syncs it uses one CPU thread at 100% capacity for about 5 minutes. During that time the browsers seem to have a slightly decreased responsiveness. For example, when I type in some editor the letters sometimes don't appear for half a second or so.

I don't know how Floccus actually syncs, but it looks like it does a full sync every single time. If nothing has changed there are two scenarios that come to my mind:

If the server API knows that nothing has changed (because it has some logic to detect changes), a single request to ask if something has changed should suffice.
If the server has no business logic by its own, like e.g. a WebDAV server, asking the server for an index with all the GUIDs should be possible too. So the response would be larger, but still a single request would be enough.

If that doesn't seem possible I am would be happy to discuss alternatives, as the current logic feels very crude to me.

Originally created by @arendtio on GitHub (Mar 30, 2018). Original GitHub issue: https://github.com/floccusaddon/floccus/issues/65 ### Software versions * Browser: Firefox 59.0.1 * Nextcloud: 13.0.1 * Nextcloud Bookmarks app: 0.11.0 * Floccus: 2.0.2 ### Steps to reproduce Nothing special. 1. Initially all bookmarks are synced (about 300 Bookmarks, (very few folders, maybe none)) 2. Trigger the sync manually or let Floccus sync automatically ### Expected outcome Without any changes to the bookmarks a sync should be done within a second (max 3 seconds). ### Actual outcome Every time Floccus syncs it uses one CPU thread at 100% capacity for about 5 minutes. During that time the browsers seem to have a slightly decreased responsiveness. For example, when I type in some editor the letters sometimes don't appear for half a second or so. I don't know how Floccus actually syncs, but it looks like it does a full sync every single time. If nothing has changed there are two scenarios that come to my mind: 1. If the server API knows that nothing has changed (because it has some logic to detect changes), a single request to ask if something has changed should suffice. 2. If the server has no business logic by its own, like e.g. a WebDAV server, asking the server for an index with all the GUIDs should be possible too. So the response would be larger, but still a single request would be enough. If that doesn't seem possible I am would be happy to discuss alternatives, as the current logic feels very crude to me.

kerem closed this issue

2026-02-25 22:36:01 +03:00

kerem commented

2026-02-25 22:36:02 +03:00

Author

Owner

@marcelklehr commented on GitHub (Mar 31, 2018):

Thanks for reporting! I will investigate soon, once I've sorted out some other bugs.

@marcelklehr commented on GitHub (Mar 31, 2018): Thanks for reporting! I will investigate soon, once I've sorted out some other bugs.

kerem commented

2026-02-25 22:36:02 +03:00

Author

Owner

@marcelklehr commented on GitHub (Mar 31, 2018):

The second scenario you described is actually more or less how floccus syncs. Which is why this is odd. Some people have reported bad performance in Firefox, but I can't reproduce this behavior in my Firefox v59.0.2 (I doubt the patch version difference is the problem here, though).

Do you have Firefox sync enabled?
Could you provide a log of a sync run with sensitive information removed?

Firefox

Go to about:debugging
enable debugging
click on debug button next to floccus entry
go to floccus options and make sure the account of your choice is connected
trigger a sync by clicking on Sync now for the account of your choice.
go back to the inspector window and copy the logs after waiting for the sync to finish

@marcelklehr commented on GitHub (Mar 31, 2018): The second scenario you described is actually more or less how floccus syncs. Which is why this is odd. Some people have reported bad performance in Firefox, but I can't reproduce this behavior in my Firefox v59.0.2 (I doubt the patch version difference is the problem here, though). 1. Do you have Firefox sync enabled? 2. Could you provide a log of a sync run with sensitive information removed? #### Firefox * Go to `about:debugging` * enable debugging * click on `debug` button next to floccus entry * go to floccus options and make sure the account of your choice is connected * trigger a sync by clicking on `Sync now` for the account of your choice. * go back to the inspector window and copy the logs after waiting for the sync to finish

kerem commented

2026-02-25 22:36:02 +03:00

Author

Owner

@arendtio commented on GitHub (Mar 31, 2018):

Thanks for the nice howto. It was the first time I was 'debugging' a Firefox extension. While obtaining the log, I could see that the networking doesn't seem to be the issue, so my initial assumption was wrong :-D

Firefox Sync is not in use here.

I am not sure what you meant by 'copy the logs', so I just copied the console output (and changed sensitive information):

Starting sync process for account arendtio@https://example.com  Account.js:105:6
SERVERCREATE vISnJciLhmkU "javascript:(function(){var%20el=document.createElement('script');el.type='text/javascript';el.src='//zeman.github.io/perfmap/perfmap.js';document.getElementsByTagName('body')[0].appendChild(el);})();"  Account.js:160:8
Fetching bookmarks Object { type: "nextcloud", url: "https://example.com", username: "arendtio", password: "password", syncing: true, localRoot: "q_XflGujiFIn", error: null, lastSync: 1522524502598 }  Nextcloud.js:121:4
Received bookmarks from server Array [ Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, 293 more… ]  Nextcloud.js:170:4
Successfully ended sync process for account arendtio@https://example.com  Account.js:126:6

Overall the whole sync took about 3 minutes. To give you some perspective on what actually happened I have a few bullet points for you:

When I clicked the sync button the 'Starting sync process...' message appear right away and CPU usage jumped to 100% on one thread.
about one minute into the sync the network request was fired. It took a total of 508 ms (most of the time waiting for the server).
after the network request was finished I could see the 'Received bookmarks from server...' message
after that, it took abut 2 more minutes before the final message ('Successfully ended...') was visible and the CPU usage was reduced.

The CPU is an Intel Core i7-4770S CPU @ 3.10GHz, so not that new anymore, but it should have no problem with the job and normally all cores are <5% CPU usage.

The 'SERVERCREATE' line was probably caused by some bookmarklet. After I removed it from my bookmarks, the message disappeared, but the sync still takes a few minutes.

@arendtio commented on GitHub (Mar 31, 2018): Thanks for the nice howto. It was the first time I was 'debugging' a Firefox extension. While obtaining the log, I could see that the networking doesn't seem to be the issue, so my initial assumption was wrong :-D Firefox Sync is not in use here. I am not sure what you meant by 'copy the logs', so I just copied the console output (and changed sensitive information): ``` Starting sync process for account arendtio@https://example.com Account.js:105:6 SERVERCREATE vISnJciLhmkU "javascript:(function(){var%20el=document.createElement('script');el.type='text/javascript';el.src='//zeman.github.io/perfmap/perfmap.js';document.getElementsByTagName('body')[0].appendChild(el);})();" Account.js:160:8 Fetching bookmarks Object { type: "nextcloud", url: "https://example.com", username: "arendtio", password: "password", syncing: true, localRoot: "q_XflGujiFIn", error: null, lastSync: 1522524502598 } Nextcloud.js:121:4 Received bookmarks from server Array [ Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, 293 more… ] Nextcloud.js:170:4 Successfully ended sync process for account arendtio@https://example.com Account.js:126:6 ``` Overall the whole sync took about 3 minutes. To give you some perspective on what actually happened I have a few bullet points for you: - When I clicked the sync button the 'Starting sync process...' message appear right away and CPU usage jumped to 100% on one thread. - about one minute into the sync the network request was fired. It took a total of 508 ms (most of the time waiting for the server). - after the network request was finished I could see the 'Received bookmarks from server...' message - after that, it took abut 2 more minutes before the final message ('Successfully ended...') was visible and the CPU usage was reduced. The CPU is an `Intel Core i7-4770S CPU @ 3.10GHz`, so not that new anymore, but it should have no problem with the job and normally all cores are <5% CPU usage. The 'SERVERCREATE' line was probably caused by some [bookmarklet](https://github.com/zeman/perfmap). After I removed it from my bookmarks, the message disappeared, but the sync still takes a few minutes.

kerem commented

2026-02-25 22:36:02 +03:00

Author

Owner

@arendtio commented on GitHub (Apr 1, 2018):

I took another look into the issue and found out, that the Parallel.each calls in sync_deleteFromServer and sync_update are the loops which take most of the time (Account.js). Btw. during the sync the refresh rate seems to drop to 0.92 fps which might explain the increased input delay.

I don't know what the polyfills are about, but I wondered a little how often I found myself within the polyfill.js during debugging. Are there any polyfills required with FF 59?

@arendtio commented on GitHub (Apr 1, 2018): I took another look into the issue and found out, that the `Parallel.each` calls in `sync_deleteFromServer` and `sync_update` are the loops which take most of the time (Account.js). Btw. during the sync the refresh rate seems to drop to 0.92 fps which might explain the increased input delay. I don't know what the polyfills are about, but I wondered a little how often I found myself within the polyfill.js during debugging. Are there any polyfills required with FF 59?

kerem commented

2026-02-25 22:36:02 +03:00

Author

Owner

@marcelklehr commented on GitHub (Apr 2, 2018):

So, it appears, the reason why I didn't experience the performance drop in Firefox probably was that I have an SSD. Firefox apparently reads bookmarks from disk and thus naive usage of its APIs dramatically slows down performance. I've refactored the sync process in v2.0.3 to read all bookmarks from the API in one go to avoid overloading disk usage. Please try the latest version, once it's approved on AMO.

@marcelklehr commented on GitHub (Apr 2, 2018): So, it appears, the reason why I didn't experience the performance drop in Firefox probably was that I have an SSD. Firefox apparently reads bookmarks from disk and thus naive usage of its APIs dramatically slows down performance. I've refactored the sync process in v2.0.3 to read all bookmarks from the API in one go to avoid overloading disk usage. Please try the latest version, once it's approved on AMO.

kerem commented

2026-02-25 22:36:02 +03:00

Author

Owner

@arendtio commented on GitHub (Apr 2, 2018):

I doubt that it is related to the SSD. Those use-cases would have been caught by the filesystem cache, I've got a SSD here too and the CPU was clearly the bottleneck ;-)

Nevertheless, the issue seems to be fixed with 2.0.3. I had some trouble with the sync after the update (it started a full sync and after a while it tried to create a bookmark that existed already), so I deleted the account and created it again. The initial sync to a minute or so and since then all syncs take only about a second 👍

@arendtio commented on GitHub (Apr 2, 2018): I doubt that it is related to the SSD. Those use-cases would have been caught by the filesystem cache, I've got a SSD here too and the CPU was clearly the bottleneck ;-) Nevertheless, the issue seems to be fixed with 2.0.3. I had some trouble with the sync after the update (it started a full sync and after a while it tried to create a bookmark that existed already), so I deleted the account and created it again. The initial sync to a minute or so and since then all syncs take only about a second :+1:

kerem commented

2026-02-25 22:36:02 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Mar 21, 2023):

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions[bot] commented on GitHub (Mar 21, 2023): This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/floccus#66

No description provided.

Rows
Columns