beneroth changed the topic of #picolisp to: PicoLisp language | The scalpel of software development | Channel Log: https://libera.irclog.whitequark.org/picolisp | Check www.picolisp.com for more information
aw- has joined #picolisp
tankf33der[m] has left #picolisp [#picolisp]
rob_w has joined #picolisp
rob_w has quit [Ping timeout: 256 seconds]
rob_w has joined #picolisp
rob_w has quit [Read error: Connection reset by peer]
rob_w_ has joined #picolisp
<beneroth> abu[m], reducing fragmentation by having specific database files for specific entities (instead of having all entities with similar blocksize in same single database file) should (theoretically) improve probability of hitting filesystem cache, agreed?
<beneroth> or is this academic, either go full benchmark and optimize for real or just keep one file per blocksize for simplicity (and storage space optimization) ?
<abu[m]> Only if those near entities are likely to be accessed at the same time
<abu[m]> More important is not to spread single objects across distant blocks
<abu[m]> they are always accessed at the same time
<beneroth> yeah agreed
<abu[m]> And to have tree nodes close to each other
<abu[m]> Best one tree per file
<abu[m]> So as far as I measured, the index trees are the critical part, not the objects
<beneroth> T, I see. Though I have way to many trees for that.. probably only worthwhile to give the most used trees their complete own file
<abu[m]> That's why 'create' imports one tree after the other
<beneroth> ok, yes makes sense
<beneroth> I do a big dump import, with a single commit at the end.. this might still spread the tree all over the place, right?
<beneroth> yeah I guess it does
<abu[m]> yes
<beneroth> I see. thanks
<abu[m]> Instead of a single commit at the end, one every 10000 objects or so seems best
<abu[m]> (at (0 . 1000) (commit))
<beneroth> T, though no influence on external symbol / tree fragmentation I guess
<abu[m]> right
<beneroth> allocated per-need / first-ask-first-served
<abu[m]> If the whole DB fits into RAM, a single commit may be fine though
<beneroth> so 'create' would be best re-allocation for lowest fragmentation, or a file per index
<abu[m]> Yes
<beneroth> thank you :)
<beneroth> afk
<abu[m]> cu ☺/
aw- has quit [Quit: Leaving.]
<beneroth> re
<beneroth> abu[m], I've got 205 indexes in a database here. So not sure if giving each its own file is really good idea (possible though) :D
<abu[m]> Is it really so critical?
rob_w_ has quit [Quit: Leaving]
<beneroth> abu[m], certainly not :D
<beneroth> I know the handful important index, will give them their own files, and the rest will be assigned according to size :)
<abu[m]> Should be just perfect 😉
<abu[m]> Yes, that's best
<beneroth> 😉