On Saturday, February 16, 2019 at 10:04:46 AM UTC+1, Egon wrote: > > Yeah, mmap is a valid solution. > > Of course, you end up with code that works less reliably on all platforms. >
Not only that, but SliceHeader is not subjected to API stability promise: https://golang.org/pkg/reflect/#SliceHeader Manlio Perillo > And, depending on what kinds of operations you are doing you might not get > a perf benefit. > > On Friday, 15 February 2019 19:34:55 UTC+2, Jeroen Massar wrote: >> >> Hi folks, >> >> Silly question time, to get to the most idiomatic golang based >> solution... >> >> In C, when I have a large collection of structs with data (no pointers >> outbound), I would just mmap a large file and chunk up the file into the >> size of the struct, basically thus doing a bit of memory management myself. >> Then with the offset * structsize, it effectively becomes a big list. >> Save/load is a sync/close + mmap away, no need to figure out what is >> loaded, cached, in memory etc or fight the system. >> (I guess folks know the advantages/disadvantages of mmap here ;) ) >> >> I've seen the examples where folks do effectively the same in golang: >> mmap into a SliceHeader and voila. >> >> But, is there a more idiomatic way to doing this? >> >> Especially, when one wants to save and later load all these objects to >> persistent storage, the mmap model is quite nice. >> Looping through a slice/map and having to write stuff that might have >> changed (would have to track changes to objects, an option, but OS does it >> otherwise for one). >> >> Thus, go with mmap trick, or any better ideas? >> >> Greets, >> Jeroen >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
