axeluser

Hi HN! I'm the creator of CarryFit.

I built this after getting frustrated while shopping for a new backpack. I kept switching between product pages, airline websites, and random forums/YouTube videos, trying to figure out if a bag would actually fit as a carry-on across airlines I travel most. It was surprisingly tedious, so I decided to collect the data once and make it available for anyone else dealing with the same problem as a free tool, without constants asking for emails, ads, or whatever.

CarryFit lets you enter your bag's dimensions and checks them against 170+ airlines' carry-on and personal item policies. You can filter by region or specific airlines, and it shows you how well your bag fits each one.

The feature I'm most happy with is soft bag support. Soft bags can compress a bit, so the tool accounts for that flexibility when checking compliance - it makes the results more realistic.

The data comes from airline policy pages (linked for each airline), though I should mention that policies do change and enforcement varies by airport and flight load. I use it myself as a sanity check before trips, but always recommend verifying with your specific airline.

It's open source and runs entirely client-side. Would love to hear feedback or if you spot any incorrect data or got any ideas for improving this tool for the whole community.

Yeah, there's such an issue. I'll fix that later.

Aha, you're right, didn't look carefully

Hm, that's actually may be true, thank you for the heads-up

Hi, thank you for your questions: 1. The "one-line" boolean condition still has jumps in the produced JIT Asm, at least to make a short circuit to exit as soon as possible. I guess the C# compiler is far too conservative for such optimisations.

2 and 3. The "operations" are both the array's size (actually the nearest power of 2) and lookup operations. I first thought that latency should be equal for both cases, because my benchmarks may be too naive - they test lookup by sequential memory access, i.e., iterating buckets from 0 to n, and iterating from first to last element in each bucket. I'll try to experiment with a more shuffled workload in my free time. Thank you for the question. I've not thought about it deeply. Also, counting mispredictions is a good idea; I'll add this metric to my benchmarks to get a complete picture.

4. I didn't pay much attention to that because the trend was still the same, and even the ratio was similar for different counts of lookups per underlying memory layout. There was just some minor deviation, but I ignored it. Maybe I'll run more granular tests with hardware counters to catch some insights.

5. SIMD, in my opinion, would be an overhead there because for a single lookup in my configuration, I'm using a single 32-bit value, and Cuckoo Filter will touch at max 64 bits (2 lookups). However, I was planning to experiment with batching of lookups; I just haven't reached it yet.