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
inara has quit [Quit: Leaving]
inara has joined #picolisp
viaken has quit [Quit: rebooty]
viaken has joined #picolisp
rob_w has joined #picolisp
<beneroth> abu[m], do I see it correct that tree root nodes are always in the default database file 1 ?
<beneroth> for example for +Hook'ed trees, even when they have a file assigned, the root node is always in file 1 and that cannot be influenced (without changing pilDB code).
<beneroth> correct?
<abu[m]> yes, correct, same file as *DB
<beneroth> abu[m], thanks
<beneroth> does it make sense to put +Hook index in index-specific files then? how do you do it?
<beneroth> (I think yes, it makes sense)
<abu[m]> Yes, sure. Then normal way in 'dbs'
<abu[m]> (rel usr (+Need +Hook +Link) (+User))
<abu[m]> (+Ltxt nm)
<abu[m]> (rel nm (+Need +IdxFold +String) NIL usr)
<abu[m]> The first two lines are from class +Ltxt
<beneroth> yeah got it
<beneroth> abu[m], which is the biggest index block size you use?
<abu[m]> I think 6 (4096)
<abu[m]> Normally 4 (1024)
<beneroth> linux page size is (normally) 4096, so I guess going bigger is not giving more benefits really
<beneroth> yeah I have 4 (1024) and 1 (128) in use now. but I have pretty big trees (with small keys)
<abu[m]> OK. 1 seems a little too small. Minimum I use is 2
<abu[m]> Hard to say and hard to measure
<beneroth> ok
<beneroth> big block size probably slows down write speed, could it be? theoretically (ofc in practice it depends a lot, esp. as the tree must be read before writing)
<beneroth> maybe not useful to even think about this..
<abu[m]> I think more than read and write speed cache usage is critical
<abu[m]> So large blocks use more cache
<beneroth> agreed
<beneroth> thanks!
<beneroth> abu[m], +Hook indexes with large variability (many just a few entries, some thousands) are difficult to pick a size for...
<abu[m]> I would not bother about th numter of entries
<abu[m]> A single block is OK
<abu[m]> indeed ☺
<abu[m]> s/numter/number/
<beneroth> well one entry with hooked index = 1 block reserved even when its barely used
<abu[m]> ok, true
<beneroth> I ran some rough tests... smaller block size is definitely better for this case :)
<abu[m]> I think in most cases 4 is good
<beneroth> T
<abu[m]> Only if there are really long strings as keys a bigger size is needed
<beneroth> I have some.. unusual indexes :))
<abu[m]> I suspected so ;)
<beneroth> but I'm sure the schema is good as it is ;)
<beneroth> yeah.. only edge cases are interesting :D
rob_w has quit [Remote host closed the connection]
aw- has quit [Quit: Leaving.]
m42e has quit [Quit: WeeChat 3.1]
m42e has joined #picolisp