Implementation using loops instead of recursion about radix

[miekg]

ah, cool thing to benchmark. Glad it didn't make a difference, I like recursion :-)

Branching is a nice (and cheap). Let's do it.

Personally I would love to keep the recursion even with COW

[sauerbraten]

I believe recursion + COW will be slower, as it requires two walks, one down and one up, plus a parent pointer in the Radix struct. Well I'll implement the loops first, then COW and if you want to you can make a branch that uses recursion + COW ;)

[miekg]

[ Quoting <reply+i-5690049-7aa954e37> in "Re: [radix] Implementation using lo..." ]

I believe recursion + COW will be slower, as it requires two walks, one down and one up, plus a parent pointer in the Radix struct. Well I'll implement the loops first, then COW and if you want to you can make a branch that uses recursion + COW ;)

note: when you using cow, you walk to the node and then walk up (if you found
something). You can do the copying when you walk up, can't you?

grtz Miek

[sauerbraten]

yeah. and I thought what I suggested was faster, but actually you would just walk down twice, so it shouldn't make a difference really. now, what's the cleaner way, a parent pointer or recording the path when walking down?

[miekg]

[ Quoting <reply+i-5690049-7aa954e37> in "Re: [radix] Implementation using lo..." ]

yeah. and I thought what I suggested was faster, but actually you would just walk down twice, so it shouldn't make a difference really. now, what's the cleaner way, a parent pointer or recording the path when walking down?

parent pointer, it's only a pointer and this why the state is implicitly defined
in the tree (not in something you carry with you in the function)

grtz Miek

[sauerbraten]

update: I think we were wrong about two things: 1) we do not need a parent pointer and 2) we do not need to do 2 walks.

when calling Insert(), we already know we are going to change something and thus can start copying from the beginning. we walk down as far as possible without running out of characters of the key to insert. then we insert the new key-value pair, and return the new tree's root (plus the newly inserted node, maybe).
shouldn't that work?

on a side node, I still can not see a use case for this, except undoing changes maybe. perhaps you can enlighten me?

[miekg]

Good question. I've been pondering a good answer for a couple of days now. I think the big issue is: are the updates atomic. Do you always have a consistent tree even when inserting.
Assume I'm copying the tree, while another goroutine is inserting. Is the copy OK afterwards or do I have dangling pointers?

[sauerbraten]

I don't think so, since we do not have a mutex in the radix struct yet. we could put one and on inserts and remove we'd wait for the lock to get opened. still though, when you do r := radix.New() and then do q := r, q and r should point to the same tree in memory right? but when you do r, newNoe := r.Insert("something", "val"), q would not get reassigned and would still point to the old tree. this means you may not have multiple pointers to a tree for different goroutines, which is kinda silly. any practical use for this?

[sauerbraten]

Now using loops + a parent pointer.

[miekg]

[ Quoting [email protected] in "Re: [radix] Implementation using lo..." ]

Now using loops + a parent pointer.

saw it. Nice. I also include a parent pointer :-)

grtz Miek