Performance problem with tree structures

[michalkvasnicak]

In our beta application we have a performance issue with tree structure.

  query shop($slug: String!) {
    viewer {
      __typename
      id
      provider(slug: $slug) {
        __typename
        ...providerCategories
        id
        slug
        title
      }
    }
  }

  fragment providerCategories on Provider {
    categories {
      ...categoryInfo
      children {
        ...categoryInfo
        children {
          ...categoryInfo
          children {
            ...categoryInfo
            children {
              ...categoryInfo
              children {
                ...categoryInfo
                children {
                  ...categoryInfo
                }
              }
            }
          }
        }
      }
    }
  }

  fragment categoryInfo on ProvidersCategory {
    breadcrumbs {
      id
      slug
      title
    }
    id
    slug
    title
  }

When given provider has deep category tree then reading from cache is slow because categories are denormalized. But we don't need them to be denormalized.

[michalkvasnicak]

As a workaround I used graphql-type-json

[calebmer]

Also see: #1300

cc @wmertens

[calebmer]

Could you give a few more details @michalkvasnicak? This is something we want to be fast. How slow was it?

[wmertens]

@calebmer forgive me, but I feel like your team does not fully grasp how slow denormalization is.

The really nice thing about Apollo is that you can pretend that server data just floats into your app without any effort on your side. That's great.

However, if you make for example a table that shows 20 rows, and each row needs to grab a small-ish cached query, that can easily take 30ms per row, or 0.6 seconds per page, just to page through a table with only in-memory data. This is exactly what I am encountering…

This slowness is a real thing and I'm convinced it's due to denormalization.

(Secondary to that, the devtools die when I try to look at the redux state or the apollo cached data, but that's not really that important)

[calebmer]

@wmertens reads are unfortunately way to slow, that we understand. My first attempt to improve store performance was #1258, but we put that effort on the back-burner to focus on getting out a 1.0 release. Once we feel comfortable with a 1.0, this is a problem that I feel is incredibly important for us to address.

I agree and recognize the unfortunate raw numbers, there are just a number of things which could cause this poor performance. I want to make sure we are pulling the correct levers to get maximum perf impact. At first I was skeptical that total denormalization was one of the large impact levers, but I think I’m coming around to your point of view especially after seeing this issue and knowing someone else identified the same problem.

Expect movement in this area from me. It may be slow (especially because we want to get out a 1.0 first), but I definitely see this as an incredibly important issue.

[Poincare]

I'll be working on performance issues this week. Hopefully we can get some wins on read performance.

[michalkvasnicak]

@calebmer Sorry for the late response. I don't have any benchmark or charts from profiler. But in our app it caused to delay render of the new route from few ms to 2-3 seconds. When I switched it to GraphQLJSON it was performing as expected (fast).

I think that something like dataIdFromObject() but for determining if given data should be denormalized could help. Of course with different name.