Performance trick: optimistic vs pessimistic checks

[-]

BuzLightbeerOfBarCmd@reddit

Isn't this just branchless? Seems weird to frame it as "optimism" but then by the end of the article you discover they were just plugging their library.

[-]

matthieum@reddit

The optimistic vs pessimistic refers to short-circuiting.

If you mostly call these functions with non-ASCII inputs, then a short-circuiting version is likely to be faster by virtue of only inspecting a small portion of the input.

The fact that non short-circuiting version is branchless is an implementation detail, really.

[-]

dukey@reddit

Yes it's branchless. But the branch version might be faster depending on the input string.

[-]

YumiYumiYumi@reddit

Isn't this just branchless?

I'd argue it's more about what the compiler can autovectorize.

If there was no auto-vec, I'd imagine the two versions would perform comparably on an all-ASCII string (and the pessimistic version would obviously win if it encountered a non-ASCII character not close to the end).

[-]

Carighan@reddit

Conversely if you work in logistics tracking, please do not do optistic checks, lest you get the utterly weird tracking results that DHL often has.

[-]

exodusTay@reddit

why is that?

[-]

Carighan@reddit

We had very limited exposure to only a portion of their system, but it seems they had the user-facing tracking system first, and added their internal "Everything must always be scanned at all times" later.

This led to a weird mismatch, because for a variety of reasons... stuff can happen. Like the same parcel going 3x from "in storage" to "in transit to next center" within one hour and back, and stays in the storage at the end.. But the user you don't want to show that, so you just swap to in-transit on the first scan optimistically, but then right after it's put back into storage. And you cannot go back. Instead of waiting until the parcel is actually fully in transit, they have a fixed translation table that can advance some user-facing states via some scan-points into specific other states, even if the scan-points allow backtracking, reversal or way other stuff.

I wish that stuff was more pessimistic, and only advanced once it is certain things cannot revert.

And we have a lot such situations in logistics-tracking/-tracing. You can't optimistically assume that because a train is moving on a track that it is, in fact in-motion. OTOH, a train can be on schedule despite not sending you a signal for >24h at all (it's in a tunnel, but that is part of the planned route). Do you optimistically show it as still en-route? Or could the loss of signal also hint at a problem so you switch it to "no data" and send the alert for missing data?

[-]