Matthew Toseland wrote: > On Wednesday 13 May 2009 04:53:11 Evan Daniel wrote: >> On Tue, May 12, 2009 at 4:26 PM, Ximin Luo <[email protected]> wrote: >> >>> (one way of storing it which would allow token-deflate would be having each >>> indexnode as a CHK, then you'd only have to INS an updated node and all its >>> parents up to the root, but i chose not to do this as CHKs have a higher >>> limit >>> for being turned into a splitfile. was this the right decision?) >> My impression is that most of the time to download a key is the >> routing time to find it, not the time to transfer the data once found. >> So a 32KiB CHK is only somewhat slower to download than a 1KiB SSK. >> (Though I haven't seen hard numbers on this in ages, so I could be >> completely wrong.) >> >> My instinct is that the high latency for a single-key lookup that is >> the norm for Freenet means that if using CHKs instead results in an >> appreciably shallower tree, that will yield a performance improvement. > > Agreed.
ok, for larger indexes this may be better then, where there are enough keys to fill up a 32KB lookup-table. i could implement a CHKSerialser which uses this format, that automatically gets used once your index gets beyond a certain size. >> The other effect to consider is how likely the additional data >> fetched is to be useful to some later request. Answering that is >> probably trickier, since it requires reasonable assumptions about >> index size and usage. >> >> It would be nice if there was a way to get some splitfile-type >> redundancy in these indexes; otherwise uncommonly searched terms won't >> be retrievable. However, there's obviously a tradeoff with common >> search term latency. > > Yeah. Generally fetching a single block with no redundancy is something to be > avoided IMHO. You might want to use the directory insertion code (maybe > saces' DefaultManifestPutter), but you may want to tweak the settings a bit. yeah, was going to look into that at some point. thanks. X _______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
