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

Fetching posts blocks the main thread #12161

Open
jkmassel opened this issue Jul 18, 2019 · 1 comment
Open

Fetching posts blocks the main thread #12161

jkmassel opened this issue Jul 18, 2019 · 1 comment

Comments

@jkmassel
Copy link
Contributor

Steps to reproduce

  1. Open the post list for any blog
  2. Observe that PostService.syncPostsOfType takes a significant amount of main queue time (1.49s in my simulator, for the blog I was using). ContextManager.saveDerivedContext takes a significant amount of main queue time as well (0.89s in my simulator, for the blog I was using). This work should be done in a background queue to avoid the app being killed by iOS.

I suspect this issue is less pronounced for sites that don't have very large amounts of text content in their blog posts.

Screen Shot 2019-07-18 at 11 46 16 AM

@jkmassel jkmassel added this to To Do in Groundskeeping via automation Jul 18, 2019
@designsimply designsimply moved this from To Do to Prioritized iOS in Groundskeeping Jul 23, 2019
@alpavanoglu alpavanoglu self-assigned this Dec 6, 2022
@alpavanoglu alpavanoglu moved this from Prioritized iOS to In Progress in Groundskeeping Dec 6, 2022
@alpavanoglu
Copy link
Contributor

Hey @jkmassel, PostService.syncPostsOfType is indeed directly called from VC's lifecycle which would block the main thread. However the only call I could find to that function is from BlogDetailsViewController.preloadPostsOfType function. And the beginning of that function has the following snippet since 2016

    // Temporarily disable posts preloading until we can properly resolve the issues on:
    BOOL preloadingPostsDisabled = YES;
    if (preloadingPostsDisabled) {
        return;
    }

It was noted to be a temporary disabling but it has been 6 years. So I am guessing there was an another call to that service function when you have faced this issue but it was removed later on. I think we can close this issue simply because the prerequisite won't be satisfied unless somebody fixes that ages old issue.

We can link this issue to the prerequisite maybe? #6151

We can also still dispatch the service call regardless, to make it future proof, if you prefer. Though again it has been 6 years without a change there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Groundskeeping
  
In Progress
Development

No branches or pull requests

3 participants