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

Improve json recursive performance #977

Open
ParticleCore opened this issue Apr 17, 2024 · 2 comments
Open

Improve json recursive performance #977

ParticleCore opened this issue Apr 17, 2024 · 2 comments
Labels
Milestone

Comments

@ParticleCore
Copy link
Owner

Currently there are a few operations that take a performance hit that is noticeable due to brief UI lockups, these mostly occur when the comment section is loading, which can contain a significant amount of data, and deep hierarchy.

In multiple sections of the extension the root path is being passed arbitrarily, meaning the recursive function has to traverse the entire json tree even when it might not be of interest for the function using it.

Ideally this should be substituted by a specific prior root path check to ensure the data is of interest of the function, for example:

const canProceed = data => data?.["contents"]
|| data?.["videoDetails"]
|| data?.["items"]
|| data?.["onResponseReceivedActions"]
|| data?.["onResponseReceivedEndpoints"]
|| data?.["onResponseReceivedCommands"];

Problem is this might introduce bugs because there might be multiple paths for the same root and all must be covered, for example a multi-path deep node:

const items = itemContainer[i]?.["itemSectionRenderer"]?.["contents"]
|| itemContainer[i]?.["shelfRenderer"]?.["content"]?.["verticalListRenderer"]?.["items"];

However, the performance impact is noticeable so this must be improved in one way or another.

@ParticleCore ParticleCore added this to the 2.1.1 milestone Apr 17, 2024
@ParticleCore
Copy link
Owner Author

ParticleCore commented May 2, 2024

Issue seems more evident when the user is logged in, especially when loading the comment section. If the user is not logged in, there are no performance issues. This indicates that the comment payloads when logged in are significantly bigger.

The difference in seconds for processing the comment section payload when not logged in vs logged in is respectively 0.102s and 3.2s (according to a few random tests).

@ParticleCore
Copy link
Owner Author

Things have been busy lately, and I have yet to find a good way to go about this so I will likely compromise on just excluding any results that are related to the comment section for now and think of a different way to go about it in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant