I agree that the comment sounded pretty hostile, but I also agreed with the assessment that it might be better to avoid allocation in general. I know the code in the post is highly simplified, but you aren't exactly fully using "lazy iterators," at least in the post. refresh/load_hotels is still allocating new Hotels, each of which contains a one-million-element Vec. If you could reuse the existing self.hotels[id].prices Vec allocations, that might help, again at least in the example code.
On second glance, I guess this is what you're getting at with the ArcSwap comment in the post. It sounds like you really do want to reallocate the whole State and atomically swap it with the previous state, which would make reusing the prices Vec impossible, at least without keeping around two States and swapping between them.
Anyway, tone aside, I still think the comment had validity in a general optimization sense, even if not in this specific case.
Yeah, the example is not representative - in reality there's a couple of smaller vectors (base prices, meal prices, supplements, discounts, taxes, cancellation policies, ...) + lots of vectors containing indices (`for 2018-01-01, match prices #10, #20, #21`, `for 2018-01-02, match prices #11, #30`, ...), and they can't be actually updated in-place, because that would require using `RwLock`, preventing the engine from answering queries during refreshing.
(which is actually how it used to work a couple of years ago - ditching `RwLock` for `ArcSwap` and making the entire engine atomic was one of the coolest changes I've implemented here, probably worth its own post)
Makes perfect sense to me for the updates to happen atomically and avoid causing lock contention, even if that makes the loader more allocation-happy than it'd be otherwise. I've done similar things before.
What about the query path? Your post talked about 10% improvement in response latency by changing memory allocators. That could be due to something like one allocator making huge page use more possible and thus vastly decreasing TLB pressure...but it also could be due to heavy malloc/free cycles during the query getting sped up. Is that happening, and if so why are those allocations necessary? Ignoring the tone, I think this is more what akira2501 was getting at. My inclination would be to explore using per-request arenas.
Per-request arenas are a nice idea, yeah - we haven't pursued the optimizations more, because we're satisfied with the current speed, but certainly there are some things that could be improved.
In grad school I worked on three separate Fortran code bases written as early as the 80s with tens of thousands of lines, no source control or version history, no build systems or even build scripts, and no tests. I think a lot of old scientific software is in the same condition, with some mix of "if ain't broke don't fix it" and the code being very hard to refactor.
This quote from the linked PRIMA page pretty much sums up my experience porting the above code too: "I hope I am the last one in the world to decode a maze of 244 GOTOs in 7939 lines of Fortran 77 code — I did this for three years and I do not want anyone else to do it again"
Did you succeed in porting the code? It would not be easy according to my experience with PRIMA. I would be happy to learn if you have a GitHub repo of it. Thanks.
Yes, at least the parts that my research group used regularly. I ported them to Rust, though, not modern Fortran. They're also pretty specific to computational chemistry, rather than general packages like PRIMA, but I'll link them here in case you're curious anyway. I was also still learning Rust and followed the original Fortran API and naming scheme where possible, so this code could use a refactor too! But at least there are no gotos.
Yes, Brentward1 was indee quoting me (author of PRIMA) in his second paragraph. However, I was asking about the code he tried to port during his graduate study mentioned in his first one.
Yeah the article says these "aren't used anymore," but my image viewer (sxiv) complained that the gif was corrupted until I put something there. It still displayed the image, but it also complained afterwards.
Those examples contain overlap, but not in the first or last digit that is given as the solution. So from the instructions you can't tell that the intermediate list of numbers should be 8, 2, 3, you only know that the final answer is 83.
Personally, I got tired of weird quirks like this with vterm and now bind this command to the key I used to have vterm on to spawn my actual terminal (st) in my current directory. It's probably not what most people want from vterm, but I prefer it.
In org-alert we use `org-map-entries` and a simple `org-alert--parse-entry` function for stripping out the details we're looking for. Depending on what you want, it's not exactly a data structure, but maybe it will help you get started!
It already is! I've been building Emacs from the development branch for the last couple of years, and the improvements in 29 and now 30 have really been great. I barely remember the sluggishness the other comment mentions.
Indeed, but then maybe it should have been more explicit.
Memory tagging as concept is quite old, so I would even expect that link to point into Burroughs Large Systems, Lisp, or other hardware of similar vintage.
On second glance, I guess this is what you're getting at with the ArcSwap comment in the post. It sounds like you really do want to reallocate the whole State and atomically swap it with the previous state, which would make reusing the prices Vec impossible, at least without keeping around two States and swapping between them.
Anyway, tone aside, I still think the comment had validity in a general optimization sense, even if not in this specific case.