3 ms·

The word in the back of my head wasn't Verbose. It was `Expensive`. Explicit looping and checking values like that seems like the answer to 'why is our app slow

The word in the back of my head wasn't Verbose. It was `Expensive`. Explicit looping and checking values like that seems like the answer to 'why is our app slow'.

bwestergard 6y ago
The latency will be linear with the size of the JSON payload, and the constants will be tiny.
horsawlarway 6y ago
I mostly disagree with you here. Checking for the existence of a key on an object is dirt cheap. Even if you happen to have a case where it is expensive, there's absolutely nothing that says your typeguard has to take that approach. I've seen some reasonably sane code that just checks that the 'Type' field of the object matches the expected value, and the 'Version' field is the right number. It's not going to catch all the possible errors there if someone breaks the api contract, but it's a lot better than a raw cast.
eat_veggies 6y ago
You'd only do this once, at the point data is going into your app via e.g. a network request. Data from the network is an untyped blob, and all your TypeScript efforts fall apart if that blob doesn't match your expectations (which are encoded in your types). In most cases it's worth it to trade the small performance penalty for correctness, especially since the cost of fetching data is already dominated by the network and backend.
- Normal_gaussian 6y ago
  Indeed. I have recently been benching an ingestion pipeline (minor data mangling, then chuck into the db), and considered switching the exhaustive type checking off, or at least making it probabilistic. However profiling showed that less than 3% of cpu was spent on this validation, making it worth every cycle. Tbh the bench here suggests the only non algo perf worth doing would be switching to rust with pre allocated memory for each request. By the time we are up to the scale where the sin le digit gains are worth it we'll have more than enough capability for going straight to the software end zone.

The word in the back of my head wasn't Verbose. It was `Expensive`. Explicit looping and checking values like that seems like the answer to 'why is our app slow'.

bwestergard 6y ago

The latency will be linear with the size of the JSON payload, and the constants will be tiny.

horsawlarway 6y ago

I mostly disagree with you here. Checking for the existence of a key on an object is dirt cheap. Even if you happen to have a case where it is expensive, there's absolutely nothing that says your typeguard has to take that approach. I've seen some reasonably sane code that just checks that the 'Type' field of the object matches the expected value, and the 'Version' field is the right number. It's not going to catch all the possible errors there if someone breaks the api contract, but it's a lot better than a raw cast.

eat_veggies 6y ago

You'd only do this once, at the point data is going into your app via e.g. a network request. Data from the network is an untyped blob, and all your TypeScript efforts fall apart if that blob doesn't match your expectations (which are encoded in your types). In most cases it's worth it to trade the small performance penalty for correctness, especially since the cost of fetching data is already dominated by the network and backend.

Normal_gaussian 6y ago
Indeed. I have recently been benching an ingestion pipeline (minor data mangling, then chuck into the db), and considered switching the exhaustive type checking off, or at least making it probabilistic. However profiling showed that less than 3% of cpu was spent on this validation, making it worth every cycle. Tbh the bench here suggests the only non algo perf worth doing would be switching to rust with pre allocated memory for each request. By the time we are up to the scale where the sin le digit gains are worth it we'll have more than enough capability for going straight to the software end zone.