[REBOL] Re: [algorithm] Algorithm challenge: selecting a range from multiple blocks
From: moliad:g:mail at: 21-Sep-2007 14:52
yep, I agree in principle. like I said I didn't benchmark anything.
yet REBOL surprises me in the way algorythms can be optimised sometimes.
I even though of molding the data and parsing it directly... that can be
very fast too, but I then realised that there was a lot of string to integer
conversion.. so that would kill it instantly.
what I am sort of counting on is related to experience on how rebol has
behaved for me in the past (its like an educated gut feeling). the GC, the
different loop functions and the use of any/all/if/either all have profound
effects on an algorythm which sometimes defy logic.
in the past, using remove-each has had profound effects on the speed of my
copying several hundred MB of ram in rebol is remarkably effective. somehow
its quite optimised and requires very little GC intervention. On the
contrary, when you start appending/creating things the GC becomes quite a
turning the GC off in a copy loop is profoundly dangerous (watch the RAM
grow and grow at tens of MB/sec), turning it off in a destruction loop is
in my experience, the slowdown is quite exponential. if you allocate the
whole block, there is going to be little speed difference, cause the native
funcs can optimise large copies, which is not possible with smaller repeated
makes. (I'm not saying it does, only that its possible, and somehow I'd
guess this is the kind of thing Carl has looked at while cooking the
If sunanda has time to clock our approach, I'd be happy to be proven wrong,
its possible one or two little ajustments can have profound effects too
(like changing the block to a list, or a myriad of other strange changes :-)
I really just wanted to give the most compact solution possible anyways.
hehe, like they say, being right and being smart are rarely the same thing
On 9/21/07, Steeve ANTOINE <sant4-wanadoo.fr> wrote: