Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Service worker load time #292

Closed
djahandarie opened this issue Oct 28, 2023 · 2 comments
Closed

Service worker load time #292

djahandarie opened this issue Oct 28, 2023 · 2 comments
Labels
area/performance The issue or PR is related to performance kind/bug The issue or PR is regarding a bug priority/high High priority issue/PR

Comments

@djahandarie
Copy link
Collaborator

Some people seem to have issues with the service worker taking time to come back online for a new lookup (after not using Yomitan for awhile).

I think we need to do some performance analysis on the service worker load time.

(I also heard that bulk imported dictionaries seem to cause worse performance compared to dictionaries imported one by one? Not sure if it's releated.)

@djahandarie djahandarie added kind/bug The issue or PR is regarding a bug area/performance The issue or PR is related to performance labels Oct 28, 2023
@jbukl
Copy link

jbukl commented Oct 29, 2023

Looks like the indexeddb.open call being run whenever the service worker is booted.

I was getting ~6.5 seconds with just JMDict installed before the request.onsuccess was reached, and ~8 seconds with these individually imported ones (several of which are very big):

image

18 seconds with some random big JSON collection (1.3gb):

image
image

I tested it just by calculating the difference of Date objects for the beginning and end of the DictionaryDatabase prepare method and printing it.

Yomibaba seems to have similar performance, except as it uses a persistent background script, it shouldn't have the issue with slow, cold lookups.

Yomitan on Firefox seemed to load instantly with just JMDict, although I wasn't 100% sure if restarting it was similar to chrome - from my understanding this could make sense due to IndexedDB possibly performing better in some aspects there, but I could also just be restarting it wrong.

I tested a bit to see the service worker's lifetime, and it seemed like it would be terminated within the 5 minutes google mentions it to (usually within 30 seconds-2 minutes) without use, leading to a long cold boot when trying to scan Japanese text again. I assume some settings currently available in the extension being enabled could keep the service worker alive long-term as well, e.g. the backend clipboard monitor, but I didn't test any of that.

I also tried looking into the performance of opening IndexedDB connections with service workers, but I couldn't find too much about it - I can't add much on this with no knowledge of IndexedDB.

Aside from that, forcibly persisting the service worker would probably deal with it, although from what I've seen, I think a lot of people are anxious about the long-term viability of those solutions - especially since it feels like a lot of the MV3 stuff is new and uncertain (like offscreen).

@djahandarie djahandarie added the priority/high High priority issue/PR label Nov 12, 2023
@djahandarie
Copy link
Collaborator Author

Resolved by #325

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/performance The issue or PR is related to performance kind/bug The issue or PR is regarding a bug priority/high High priority issue/PR
Projects
None yet
Development

No branches or pull requests

2 participants