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

Closed
ParticleCore opened this issue Apr 17, 2024 · 6 comments
Closed

Improve json recursive performance #977

ParticleCore opened this issue Apr 17, 2024 · 6 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.

@ParticleCore
Copy link
Owner Author

Seems like the major issue of the performance problems are restricted to the comments section, so I will just exclude them from processing. It seems like it does not affect any other functionality so there aren't any known compromises.

@LazyBoot
Copy link

Chrome (129.0.6668.42) running Iridium 2.1.1 still seems to get un-responsive while loading comments. Though only on the 2nd set of comments loading per-video onwards.

As in: Initial video load, and scrolling down to comments will load fast and smoothly.
But scrolling down more until it loads more comments gets un-responsive and slow, like the old version did.

@ParticleCore
Copy link
Owner Author

@LazyBoot Can you open a new issue for that one? In might have missed something else in the logic I implemented for this one that must be different for subsequent loads.

@LazyBoot
Copy link

Done, opened as #1005

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

2 participants