Apollo-client-devtools: Devtools Completely Locking My Browser

[cbranch101]

On initial load, everything seems to work fine, but after a clicking around a couple of times, I start getting an unending stream of long process warnings for processes taking around 250 ms, about twice a second, which completely locks up the browser tab I have open. Disabling Devtools causes it to go away.

If there's anything strange about our setup that might be triggering this, I'm guessing it's the fact that we're using deeply nested fragments.

Here's an example query.

query Section {
  section {
    ...SectionHeaderSection
    ...SectionOutcomesSection
    ...SingleStudentSection
    ...StudentsMonitoringSection
    ...AppBody
    ...RouteForUser
    ...LastUpdatedSection
    __typename
  }
}
fragment SectionHeaderSection on SectionData {
  ...CourseSettingsSection
  ...AverageGradeSummarySection
  ...StudentDistributionSummarySection
  ...SectionInfoSection
  __typename
}
fragment CourseSettingsSection on SectionData {
  stats {
    averages {
      grades
      __typename
    }
    gradesStddev
    __typename
  }
  settings {
    values {
      ...SettingsMessages
      ranges
      __typename
    }
    defaults {
      ...SettingsMessages
      __typename
    }
    gradeHistogram
    __typename
  }
  __typename
}
fragment SettingsMessages on CourseSettingsFields {
  messageLow
  messageMiddle
  messageHigh
  __typename
}
fragment AverageGradeSummarySection on SectionData {
  stats {
    averages {
      grades
      __typename
    }
    __typename
  }
  __typename
}
fragment StudentDistributionSummarySection on SectionData {
  stats {
    ranges {
      grades {
        low {
          ...RangeValues
          __typename
        }
        middle {
          ...RangeValues
          __typename
        }
        high {
          ...RangeValues
          __typename
        }
        __typename
      }
      __typename
    }
    __typename
  }
  distributionMessages {
    low
    middle
    high
    __typename
  }
  __typename
}
fragment RangeValues on StatsRange {
  max
  min
  value
  __typename
}
fragment SectionInfoSection on SectionData {
  name
  stats {
    studentCount
    __typename
  }
  code
  number
  __typename
}
fragment LastUpdatedSection on SectionData {
  lastUpdated
  __typename
}
fragment AppBody on SectionData {
  user {
    type
    __typename
  }
  __typename
}
fragment StudentsMonitoringSection on SectionData {
  code
  ...HelpSection
  ...SearchToolsSection
  __typename
}
fragment HelpSection on SectionData {
  ...IsDataAvailableSection
  __typename
}
fragment IsDataAvailableSection on SectionData {
  statsAvailable
  __typename
}
fragment SearchToolsSection on SectionData {
  ...IsDataAvailableSection
  __typename
}
fragment SingleStudentSection on SectionData {
  user {
    type
    __typename
  }
  ...DetailedInfoSection
  ...StudentChartsSection
  __typename
}
fragment StudentChartsSection on SectionData {
  dateStart
  dateEnd
  user {
    type
    __typename
  }
  __typename
}
fragment DetailedInfoSection on SectionData {
  user {
    type
    __typename
  }
  ...StudentFlagsSection
  ...DetailedInfoHeaderSection
  __typename
}
fragment StudentFlagsSection on SectionData {
  settings {
    values {
      messageLow
      __typename
    }
    __typename
  }
  user {
    type
    __typename
  }
  __typename
}
fragment DetailedInfoHeaderSection on SectionData {
  ...ContactButtonSection
  __typename
}
fragment ContactButtonSection on SectionData {
  user {
    type
    __typename
  }
  instructors {
    name
    address
    enrollmentType
    __typename
  }
  __typename
}
fragment SectionOutcomesSection on SectionData {
  code
  ...SectionChartsSection
  ...SectionFlagsSection
  __typename
}
fragment SectionChartsSection on SectionData {
  user {
    type
    __typename
  }
  charts {
    assignments
    engagement
    quizzes
    __typename
  }
  __typename
}
fragment SectionFlagsSection on SectionData {
  user {
    type
    __typename
  }
  settings {
    values {
      messageLow
      __typename
    }
    __typename
  }
  flags {
    text
    __typename
  }
  __typename
}
fragment RouteForUser on SectionData {
  user {
    type
    id
    __typename
  }
  __typename
}

I don't know if this relevant as well, but we've also been having trouble with filter and propTypes from graphql-anywhere eating up a lot of CPU as well.

[jblank46]

I believe I'm seeing similar behaviour. I am not sure if this is related or not, I thought about posting a topic for this but haven't submitted. When I'm using the Apollo dev tools, I see its ram usage increasing over time consistently. I also see it spiking cpu usage for extended periods of time and can't tell why. I left the window up overnight and when I got back to my machine, my react app chrome tab was using 1.5gb ram at that point. I killed the extensions window and it released the memory. I've only started seeing this behaviour with the Apollo dev tools. If I remove apollo dev tools, I never see this behaviour.

Not sure if it matters or not but I have the react, redux dev tools and apollo dev tools all installed. This is on windows 10, chrome version Version 57.0.2987.110 (64-bit).

[slackday]

Same problem here instantly when opening dev-tools and making 2-3 clicks in App.

Mac OSX Sierra 10.12.3
Chrome Version 57.0.2987.133 (64-bit)

Friend also reporting same problem on his Unix system.

Any suggestions how to troubleshoot this further?

edit

Interesting note might be that the App freezes almost completely but the devtools itself is responsive. Other tabs work fine.

Using babel, browser-sync and webpack.

[cbranch101]

After digging a little deeper, I think this function might be at least part of the issue.

https://github.com/apollographql/apollo-client-devtools/blob/master/app/components/Inspector/Inspector.js#L63-L69

It seems like what's happening is that something inside of updateData slows down to the point that it takes longer than 500 ms to run, and because it's on an interval, that function is basically running all the time, and locks the whole tab.

[FreddieRidell]

Experiencing (probably) the same problem, only started recently and renders my App unresponsive

[helfer]

Thanks for filing the issue @cbranch101! I think your assessment is correct. @rrdelaney has volunteered to help out, and is looking into how we can avoid the costly copying.

[FreddieRidell]

Any progress on this? It's still happening on both my PCs

[rrdelaney]

Still working on it! It's a pretty big part of the devtools and I'm still working on it 🙂

[stubailo]

Yeah, basically we need to rearchitect how the devtools communicate with the application. Right now it's copying all of the state on an interval and making it do something else is a big effort. We're also getting some interns joining the Apollo team soon and I hope one of them can help write a totally new system :]

[thomassuckow]

Seems like rather than setting an interval or setting timeout at the beginning of a polling cycle it could setTimeout at the end so at least you get half a second of work done between polls as a stop gap.

[tnrich]

Dunno if my PR will help but it seems like it could alleviate things in the short term:

https://github.com/apollographql/apollo-client-devtools/pull/45

Basically I changed the interval time from 500ms to 5000ms and it seems to help things in my app at least. I bet that given enough watched queries things the updateData will slow down past the 5000ms mark but at least it doesn't happen after just a couple any more.

[geelen]

Just hit this problem as well. @tnrich's PR could be an easy fix but this sounds potentially even better & might be doable without rearchitecting anything:

Seems like rather than setting an interval or setting timeout at the beginning of a polling cycle it could setTimeout at the end so at least you get half a second of work done between polls as a stop gap.

[geelen]

I just realised this could be something related to live reloading? It seems to happen after I've been making a few edits, potentially there are lots of setInterval calls happening, which cause them all to slow down, and then the forkbomb occurs...

[tnrich]

@thomassuckow I've expanded upon your ideas in https://github.com/apollographql/apollo-client-devtools/pull/53

@cbranch101 I also realized that the same thing was happening in Panel.js

After digging a little deeper, I think this function might be at least part of the issue.

https://github.com/apollographql/apollo-client-devtools/blob/master/app/components/Inspector/Inspector.js#L63-L69

It seems like what's happening is that something inside of updateData slows down to the point that it takes longer than 500 ms to run, and because it's on an interval, that function is basically running all the time, and locks the whole tab.

[rrdelaney]

Just merged #53 - let's see if it helps 😄

[ramyanaga]

@cbranch101 Is this still a problem?

[tnrich]

I believe that this is no longer an issue

On Wed, Jul 12, 2017, 6:57 PM Ramya Nagarajan [e-mail]
wrote:

@cbranch101 https://github.com/cbranch101 Is this still a problem?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apollographql/apollo-client-devtools/issues/28#issuecomment-314921022,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACmqcTj9zj_ZMCuV4LcadbxQP3sIXdrwks5sNU8vgaJpZM4MwiAs
.

[cbranch101]

Yep, this fixed it for me, thanks guys!