I got a little question which might be obvious for long-term devs, but I’m still unsure. And because so many of those explanation stuff in the web is LLM-generated these days, I would prefer replies from some of you experienced (Zig)devs :slightly_smiling_face: The scenario: I have a larger main da…

If you are working with copies, then just store DataStruct directly in the hash map. There is no benefit of the separate array here. If you want to work without pointers, you could imply have this API: pub fn add(self: *CacheMap, item: DataStruct, ident: u64) !void; pub fn update(self: *CacheMap, i…

if you care about performance benchmark. regarding memory management/robustness, holding a long term pointer into an unstable collection is ill-advised, which a hashmap could be depending on how you use it. related to that is: have you tried/able to use a handle instead of a pointer?

I haven’t found a good way to benchmark this. But tbh performance should be a minor problem. The items stored in the hash map have a unique u32 as key which is very very unlikely to match a duplicate. To be precise the keys are directory inodes (which in theory could be reused, but not during the r…

[image] lukeflo: Sorry for the maybe dumb question, but what do you mean by “handles” in this case? andrew has a talk on the subject Video: Programming without pointers

Yeah, indeed I watched the video multiple times, but am not sure how I could apply this to my code. But if thats a preferred way I might have to wrap my head around this even more :smile: However, since this approach is something different, I would assume that there is no real difference between us…

[image] lukeflo: main_struct.active_item = main_struct.item_cache.getPtr(346562).?; This is dangerous in a non-obvious way. Only do this, if you are absolutely sure nothing will write to item_cache while you hold the reference to the value. Any change to the hashmap can invalidate the pointer…

Thanks. However, the SubStruct is only an example. The original “substruct” has several more fields containing different types (strings, integers, other structs). And as stated it has to be updated while it is active. E.g. for the used example the SubStruct.string value could be changed and this cha…

Then I’d store pointers in the hashmap. But once you bring pointers into the code, you need to think about their lifetime. Since it’s a cache and not concurrently used, it’s probably easy enough to clean up entries once they are no longer needed. In case there are concurrent inserts/update, it gets …

Actually, if you really don’t need performance, you might find that always using getPtr when you need to work with the item, and never storing any reference for “quick access”, might be the easiest and safest option and still fast enough, since I don’t expect your hash table to be huge, if it’s for …

[image] lalinsky: Only do this, if you are absolutely sure nothing will write to item_cache while you hold the reference to the value. Any change to the hashmap can invalidate the pointer and you get hard-to-debug crashes. By the way, this is the exact use case for HashMap.lockPointers().

[image] lalinsky: Since it’s a cache and not concurrently used, it’s probably easy enough to clean up entries once they are no longer needed. Yes, no concurrent usage in the whole code for now. I want to keep it single threaded/non-concurrent if possible. Mainly exactly because I don’t want t…