Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • So you highlight "Not AI Gen" but you call the solution "Agent"? :D
    by mrbluecoat
  • OT but… it’s nice to see someone use a legible font with good character height and line spacing

    Makes the post a joy to read

    by youngtaff
  • Simple memoization yields massive wins. Had similar experience with a hot loop, sometimes the basics are just magic.
    by Eastmill
  • How do your path-only rules handle the many approaches for loading a file but making it appear to have a different path, such as bind mounts for one example?
    by ComputerGuru
  • How is the cache invalidated when: - The permissions change? - Directories are moved? - Hard-links are added? - Things are deleted? Also: Is the cache limited in size?
    by brookman64k
  • Seems like the 90% faster case is opening the same exact file every single time, which seems like a not super standard use case that will benefit the most from this caching. On an example where you never open the same file twice this will presumably be slightly slower than before, as you’re doing the same thing but writing to a cache. So you can make the headline “Drop performance cost by 90%!” or “Modestly increase performance cost” and be correct but I don’t think either is really a reasonable description of the change.
    by Allybag
  • Very confused by the article. Is memoization new to the eBPF world? Did the author only just learn about it and wanted to use it?

    In reality, the article is about correctly caching a path:policy mapping while working within the limitations of eBPF and Linux filesystem semantics. If you read the article in that context rather than wondering 'what is new and interesting about memoization in eBPF?' it's a lot more interesting.

    I probably would have titled this 'Calculating cache keys for filesystem paths in eBPF' or something, since that's the cool and interesting problem that was solved.

    by danudey
  • Memoization trades compute time for memory: you reduce CPU cost by 90% _at the cost_ of some memory. The author measured one, but it doesn't look like they measured the other.

    It's an important detail to take into account. I'm sure this optimization makes sense, and the size of additional memory is not that big, but I believe it's good to "measure, not assume" as some load bearing model might say.

    by salviati

Explore Birbla archives