isFieldAvailableOnType and getField from exchanges/graphcache/src/ast/schemaPredicates.ts too slow in the react-native env

[alexesDev]

Hi. I see what isFieldAvailableOnType and getField too slow due to the non-optimized code...

export const isFieldAvailableOnType = (
  schema: SchemaIntrospector,
  typename: string,
  fieldName: string
): boolean =>
  BUILTIN_NAME_RE.test(fieldName) ||
  BUILTIN_NAME_RE.test(typename) ||
  !!getField(schema, typename, fieldName);

You can use startsWith or indexOf instead test. And also this condition rechecked in getField

if (BUILTIN_NAME_RE.test(typename) || BUILTIN_NAME_RE.test(fieldName)) return;

I'm right?

https://github.com/FormidableLabs/urql/blob/f4266f29cc9e55affe4c952701c8a034435bbb16/exchanges/graphcache/src/ast/schemaPredicates.ts#L67
https://github.com/FormidableLabs/urql/blob/f4266f29cc9e55affe4c952701c8a034435bbb16/exchanges/graphcache/src/ast/schemaPredicates.ts#L42

[JoviDeCroock]

That code isn't used in production though, it's dev-only code https://github.com/FormidableLabs/urql/blob/f4266f29cc9e55affe4c952701c8a034435bbb16/exchanges/graphcache/src/operations/query.ts#L304

EDIT: but getField is used outside of it 😅

[alexesDev]

Ohh. Ok, in the production mode, isn't a problem.

I have a big query, but not huge (https://gist.github.com/alexesDev/4c2bf9106220a8c920b55f38d83e5bc9, 1.5k SKU). Can you say who I can optimize this? 🤔 Or it is a hermes (js engine for react-native) problem?

[JoviDeCroock]

This PR is in anyway 😅 #1957 generally haven't had any issues in query traversal personally but my experience limits itself to web currently. I can try and explore the speed in react-native but afaik the graphcache traversal is one of the fastest ones (see our benchmark folder)

[kitten]

Hermes may indeed be causing some trouble here. At least some of these ratios I can see in that zoomed in view doesn't really make sense to me; even if it was with a CPU slowdown.

Could you leave me a dump of this CPU trace somewhere? I'd be super curious to see the size of the data against this trace

[alexesDev]

@JoviDeCroock thx
@kitten I sent the dump to your email [email protected]

[kitten]

@alexesDev Thanks for sending a trace over! I've also sent it to @kadikraman, who knows a great deal more about React Native than I do. I've also queried your API and I've seen that the overall payload is around 2.1MB. Are you sure you aren't overfetching here? 😆 I know this is a lot of data and (in production) two seconds may be an appropriate time to process it, so just in the interest of time here, would you say that a multi-second time may not be expected here?

[alexesDev]

No, it isn't overfetching and needed for offline in the feature. I can remove some large fields (like product.info) and reduce the response size to ~100kb and this doesn't change anything. We are looking for a solution and I will notice you if we found.

[kitten]

ok great, so no offense, but you managed to say slow a lot without actually giving us numbers, which I'm a little stumped by. So, saying that it doesn't change with a smaller response (which is also just a heuristic) doesn't do much for us. However, have you tried this without Hermes? We have benchmarks that would indicate that there'd have to be quite a lot of data for a cache normalisation (i.e. write) to be 2s+ slow. Even if it wasn't Hermes, I'd actually wager that this isn't optimal. And if this is down to you downloading a long list of data all at once, then you can't get this fast in any system.

To put this another way, I understand that "downloading everything" (if that's the goal?) may seem good, however, what if tomorrow you decide to 2x your data? That's not a rare thing, I suppose. Would it then be acceptable to be half as slow? What if the device it's running on is half as fast? What if the list grows in complexity and length by 10x?

In other words, Graphcache is already approximately 80-100% faster than [other GraphQL client that shall go unnamed 😄]. We can't really get a 10x performance improvement out of this. We basically are at a limit where we can't get another order of magnitude. So, even if we found an issue with Hermes (since we're assuming JSC would speed this up already) and would speed this up by, say, 10%, that wouldn't really be enough. 🤔

I hope that gives you some food for thought. If it helps, I've delivered offline capable apps. Heck; Twitter is always a great example. And not a lot of apps need to be 100% offline ready, and often they can't be since edits won't always make sense offline. Some apps obviously have higher requirements, but at that point it may make sense to then ensure that an update of the data is either visible to the user (if it's slow) or happens somewhat asynchronously.

Edit: I forgot to add; the 10% I hinted at isn't invented 😆 the point here was that with speeding up updateDependencies we may get a small uplift. But yea, -10% off of 2s isn't enough and won't be enough 🐎