Hacker Newsnew | past | comments | ask | show | jobs | submit | axeluser's commentslogin

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.


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.


> 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

Yeah; that completely eliminates the cache misses / memory latency you'd have in practice. Of course eliminating that bottleneck is useful if you want to purely optimize CPU speed, but probably not quite as representative of real workloads. Also makes sense then that different array sizes give similar results: streaming tends to be fast anyway, regardless of the array size.


The one liner shouldn't have shortcircuiting since it uses the binary or |, not the boolean/logical or||.


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


Thank you! You are right. Cuckoo Filters use the open-addressing technique to deal with collisions, which may result in a long eviction chain on inserts or even fail if the load factor is high or just bad luck. This is one major drawback you should consider before using it. https://maltsev.space/blog/010-cuckoo-filters#fingerprints-a...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: