magic_lobster_party

  • 0 Posts
  • 19 Comments
Joined 4 months ago
cake
Cake day: August 15th, 2024

help-circle
  • Basically it’s just an optimization of a double nested for loop. It’s a way to avoid running the inner for loop when it is known there will be no hit.

    This is useful when we for example want to find all product orders of customers in a particular country. The way we can do this is to first filter all customers by their country, and then match orders by the remaining customers. The matching step is the double for loop.

    Something like this:

    for order in orders:
        for customer in customers_in_country:
            if order.customer_id == customer.id:
                …
    

    Many orders won’t match a customer in the above query, so we want to single out these orders before we run the expensive inner for loop. The way they do it is to create a cache using a Bloom filter. I’d recommend looking it up, but it’s a probabilistic cache that’s fast and space efficient, at the cost of letting through some false positives. With this particular use case it’s ok to have some false positives. The worst thing that can happen is that the inner for loop is run more times than necessary.

    The final code is something like this:

    bloom_filter = create_bloom(customers_in_country)
    for order in orders:
        if bloom_filter.contains(order.customer_id):
            for customer in customers_in_country:
                if order.customer_id == customer.id:
                    …
    




  • I hate when coworkers tell we should do thing in a particular way because it’s ”better”. We try the thing and there’s no measurable difference. Well, it was a good idea in their mind, so it must be an improvement. Therefore, they insist it should be kept, even if it makes the code extra convoluted for no reason at all.

    And yes. Profiling is great. Often it is a surprise where most time is spent. Today there’s few excuses not to profile since most IDEs has a good enough profiler included.




  • I agree with the first point. Always go for clarity over cleverness.

    I somewhat disagree with the second point. Consistency is important. Stick with the same name when possible. But I think mixing camel case and snake case should be avoided. It can make the code less ”greppable” IMO, because now you need to remember which casing was used for each variable.

    Kind of agree on the third point. I think flatness should be preferred when possible and when it makes sense. Easier to find the variables with the eyes rather than having to search through nested structures.










  • A favorite from this year is the trailer for Doom: Dark Ages. Excellent pacing. Weapons I’m waiting to get my hands on. It makes it clear how it’s going to set itself apart from the previous entries, and I’m hyped for it.

    An all-time classic will forever be the first trailer for Zelda: Twilight Princess. At the time it was the right trailer for a new Zelda. People wanted a ”proper” Zelda after Wind Waker, and what they presented was just mind blowing. In the end I didn’t enjoy TP as much as I wanted, but that first trailer still gives me goose bumps. At least TP made me find a new appreciation for WW.