AltME groups: search

Oh my, SVG, what a pain...
Some strange bugs, i can't figure...

As you can see here http://sites.google.com/site/rebolish/test-1/lizard-grad-err.png

I've got some problems to map correctly the gradients on the shape 
they are supposed to cover.

i can't figure why the coordinates of the gradients in the SVG file 
are wrong.

It's not clear (http://www.w3.org/TR/SVG11/pservers.html#Gradients) 
where the gradients should start....

I've been playing with Shadwolf/etc SVG 06 svg renderer today and 
am at the point where i am working on linking in gradients.  The 
test SVG i am using (because it seems to be a good mix) is http://en.wikipedia.org/wiki/File:SVG.svg

Currently my problem is with the linear gradients when a matrix operation 
is applied on them.


The linear gradient use a vector v = (x1, y1) - (x2, y2) to indicate 
his direction and length.


grad-pen is defined like this:  [grad-pen linear normal xy 0 len 
angle [... stop colors]]

And i calculate his values with:

- xy = (x1,y1)
- len =  length of the vector v 
- the angle of the vector v


When a matrix is associated with the gradient, i multiply the coordinates 
of the vector v by the matrix before calculating the other values.
It's working well when the gradient is vertical or horizontal.

But when the gradient is inclined , the matrix multiplication give 
a wrong vector and i don't know why.

To be precise, the resulting vector seems to have the correct position 
and length, but a wrong angle.

when matrix transformations are applied, some are wrong, but hey 
! Quite a good result already !

This matrix must not be applied on the gradient's vector as-is, but 
on something else.
And i found what, at least...


The documentation of SVG is lacking of a good explanation about this 
curious matrix transformation.
All we can read is that curious sentence:


When the object's bounding box is not square, 
the stripes that are 
conceptually perpendicular to the gradient vector within object bounding 
box space 
will render non-perpendicular relative to the gradient 
vector in user space 
due to application of the non-uniform scaling 
transformation 
from bounding box space to user space

What does that mean ?????


It means that the SVG gradient must be rendered without using the 
matrix transformation.

And THEN the transformation matrix must be applied on the resulting 
strips.

You see the problem ?

The matrix must not be apllied on the gradient's vector, but on the 
resulting strips produced by the use 
of the initial gradient's vector.


What foolish morons have designed such a complicated way of constructing 
gradients.

Can't they just give a matrix that can be applied on gradient's vector 
as-is, no they can't, it's to simple.
Morons, I said !!!


Because of that i had to make more transformations to obtain the 
REAL vector.
step by step I do something like that:


1/ Take the initial gradient vector V and apply the matrix on it, 
it gives a vector V1

2/ RE-take the initial vector V, rotate it of 90 degrees, apply the 
matrix on it, and rotate back the resulting vector
. It gives the vector V2

3/ Project the vector V1 on the line V2 (orthogonal projection). 
It gives a third vector V3.
4/ That's all, the REAL vector to use for the gradient is V3.


It take me a while to figure that, by analysing the Inkscape rendering. 
Morons i said !!!

Well i thought SVG 's radialGradients will be easier. I was wrong.
SVG Proposes another stupid feature (yet another one).
Actually they can specify 2 circles.

One where the gradient is really rendered. And another one used as 
a window which clips the first one.
What the heck is that !!!!

it's why in a SVG's radial gradient, there is 2 different  centers 
 (cx, cy) (fx, fy)  for the 2 separated circles.


When the 2 centers are equals, then there is no prolem to render 
it whit the rebol's radial gradient, easy.
But when they differ, it's impossible.

I can't blame Rebol to not allow that, because it's a really stupid 
useless feature.

in fact, i think i could simulate that behavior.
By 
1/ rendering the radial gradient in the initial circle.

2/ create an image with that circle and clip it with the shape of 
the second one.
3/ Use that image as a pattern for the fill-pen attribut


But it would be a mess of  computing time and of memory, because 
in the draw block we would have images used as pattern instead of 
computed gradients

By default Inkscape don't use that feature when you design a radial 
vector.

Ok, i finished with Radial gradients (less the impossible feature: 
2 different centers)


SVG use a matrix transformation to convert a circular radial gradient 
into an ellipsoid.

And you know what ? 

We can do the same thing with grad-pen which provides 2 scalling 
factors (grad-scale-x and grad-scale-y)

So in that case it's easier than for linear-gradient.
1/ take the focal point of the Radial gradient (fx, fy)

2/ Create 2 vectors starting from this point: 1 vertical and 1 horizontal, 
using the radius as their length.
3/ apply the matrix transformation on them.

5/ get  the component X of the transformed horizontal vector, and 
the component Y of the transformed vetical vector
6/ grad-scale-x:  x / r
7/ grad-scale-y: y / r

That's all folks

Added a litte animation.
The bumping lizard !!!!
http://sites.google.com/site/rebolish/test-1/lizard.r

the difference in your render and SVG render is mainly the anti-aliasing, 
which is crisper in the svg renderer.... probably has a better algorythm 
setup than the one use by R3... this is probably manageable within 
AGG, but AFAIK there is no control for it within R3.

Not the problem of the antialiasing, I just think i made a false 
translation of the command used in the shapes.

They use a smouthing curve, me not i guess. I have to verify that.
But Rebol can draw smoothing curves too, no problemo.

if you draw the outlines twice, they should be a bit crisper... is 
that what you mean?

also the anti-aliasing was a result of my browser which rescaled 
the image minus 5 pixels... so it has nothing to do with your render.

It's a good one. It looks identical to yours, though that may be 
server side in your example link.

They probably call the same code internally, but the draw function 
may be crashing in a non-shared portion of its code.

I'd put a :( on that.

You know it's a problem when you can't replicate the bug and focus 
clearly what the problem is.
Carl put a spell on me because of that (in his last note)

that's not what i got.
i got a blank screen when an error occurs.

wahoo ... lot to read .. T___T  basically there is in Draw/AGG some 
limitations due to gradient  system and matrix translation bugs i 
don't know if they have been solved  since i pointed a them ...

i'm fighting with several e-commerce solution (free ware) for a client 
i want to die ... how can web 2.0  without rebol can be such a pain 
T___T

Oscommerce, thelia, virtuemart, prestashop, magento, zencart, OSCC 
... have cool back offcie cool functionnalité but when you don't 
want to fit to the header, menu, left_col, document, right_col, footer 
design  you are face big troubles allmost all the engine in those 
product is to be remade....

can't anyone shake that area and put rebol in it ....  something 
like a rebol os-commerce all strong and mighty in 200Ko ... Ok you 
can go to 2Mo last limit... lol

(and yeah you will say to me but why you don't do your solution os-commerce 
like based in rebol ?)

hum the amount of  capabilities in a e-shop web site clients are 
used to see now in days  are big...

Stat tools,  catalog edition, shiping, card. And then the hosting 
solution simply doesn't know about rebol so if it's not apache/php/mysql 
or apache/java/mysql  you are fried unless you have full access to 
the hosting solution and you are able to install what ever you want....(cheyenne!/rebol/mysql-protocol 
etc...)

on my computer your annimation is lighting fast ... (maybe too fast) 
it's a very lively lizar lol

As far i am, i made some useful tiny mezz, perhaps some could be 
in R3.

reuse: funco [b [block!]][head reduce/into b clear []]

** REUSE, reduce a block, but re-use always the same block 

** Actually, 3 time slower than a reduce block, but save memory and 
GC recycles if used massivly.
** I use it to pass small blocks of coordinates.

mulm: func [

 {multiply a matrix [a b c d e f] by coordinates x y, return coordinates 
 [x' y']}
	x y m [block!]
][
	reuse [x * m/1 + (y * m/3) + m/5 x * m/2 + (y * m/4) + m/6]
]

atan2: func [

 {Angle of the vector (0,0)-(x,y) with arctangent y / x. The resulting 
 angle is extended to -pi,+pi}
	x y
][
	if x = 0 [x: 0.0000000001]
	add arctangent y / x pick [0 180] x > 0
]

Project: func [

 {orthogonal projection of a point P on a line AB, return coordinates 
 [x y]}
	ax ay bx by px py
	/local sx sy ux uy ratio
][
	sx: bx - ax
	sy: by - ay
	ux: px - ax
	uy: py - ay
	ratio:  sx * ux + (sy * uy) / (sx * sx + (sy * sy))
	reuse [ratio * sx + ax  ratio * sy + ay]
]


vector-length: func [x1 y1 x2 y2][square-root add x2 - x1 ** 2 y2 
- y1  ** 2]

plink is a ssh command line tool  of the putty package

maybe win-call uses a different home directory for the key file

I have a problem with cheyenne-r0920-cmd.exe on Windows, when I comment 
database section in my http.cfg it works, when I uncomment it gives 
the following error in chey-pid-9036.log file:


25/1-17:58:14.625-## Error in [uniserve] : On-received call failed 
with error: make object! [
    code: 515
    type: 'access
    id: 'invalid-path
    arg1: "/E/cheyenne/www/centrex//index.rsp"
    arg2: none
    arg3: none
    near: [info? new [
            req/in/target: form file 
            if ext: find/last req/in/target dot [
                req/in/ext: to word! ext 
                req/handler: select service/handlers req/in/ext
            ] 
            if not req/in/file [req/in/file: new] 
            if d?: declined? req [return false]
        ]]
    where: 'throw-on-error
] !


note that there is double slash before index.rsp I don't know why. 
Error happens before I use any do-sql or something. Web page doesn't 
work at all.

Thanks for digging this up, I'll have a quick look on it later today.

Looks like a ESMTP scheme issue. Is it working from console (using 
same REBOL version)?

Code works on same machine in rebol console but I'm using exe version 
of cheyenne. Does that make a diff?

Alan, you do know Cheyenne has a built in mail server ?

The above error is on a .cgi script. cgi is on by default right?

I have a problem running cheyenne-0920-cmd.exe as a service on Windows 
Server 2003 (32Bit)
Same version runs on XP/Pro (SP3). 
Crash.log:
10-Feb-2012/12:07:10+2:00 : make object! [
    code: 500
    type: 'access
    id: 'cannot-open
    arg1: "/C/cheyenne_tt/service.dll as library"
    arg2: none
    arg3: none
    near: [do make routine! [] load/library]
    where: 'launch-service
]

My Win2003 issue is still not solved, but I have one additional question,

RSPs can read/write anywhere in the server, even they are in a webapp. 
Is it not a security hole? If someone able to upload an rsp file 
and execute it, he can delete a vital file from the system, or read 
whole directory structure.
Is there a way to run Cheyenne (or a webapp) in a sandbox?

Oh ok, I can run Cheyenne in other than LocalSystem account such 
as Guest or another limited user account so it cannot read/write 
other directories.

It's better to create a user for Cheyenne to be able to control fully.

They give very close result, WHILE looks a bit faster.

;b is a block of some numbers, benchmark func loop 1'000'000 times.

>> benchmark [i: 1 until [not if x: pick b i [++ i x]]]
== 0:00:38.953

>> benchmark [i: 1 while [x: pick b i] [++ i]]
== 0:00:35.688

On my EeePC 1.6 Ghz N270, XP/Home.

My test was on R2, may be would be different on R3.
I'm mostly agree with Gregg.

This line is in do-sql/flat function (if you use R2 native drivers, 
not in Softinnov's mysql driver) so if your resultset has millions 
of rows you gain 3-4 seconds on a slow machine.

Gregg, I know your take on optimisation... ;-)


<start rant  ;-) > If I had the same opinion, liquid would still 
be 10 times slower than it is now.   each little part of the changes 
add up and after years it really adds up.  I have some new changes 
which will probably shave off another 5-10% when they are done.  
 It requires several changes (some probably removing  less than a 
%).  its been like that since the begining.  the relative impact 
of any optimisation is always bigger the more you do it.  


the first 1% looks like nothing when you compare it to the original 
100% but after you've removed 25% its now 1.33%... but when your 
app is 10 times faster, that 1% is now 10 % of the new speed.


btw, I'm not trying to justify this specific optimisation, but I'm 
trying to balance the general REBOLer consensus that optimisation 
(in speed, code size and RAM use) isn't important when compared to 
other Reboling tasks... 
 

Have you (using "you" in the general sense, not gregg specifically) 
ever looked at Carl's Code?  its some of the most optimised and dense 
code out there... it hurts the brain... and its very enlightening 
too.  all the little variations in the series handlers often are 
there by  design and all balanced out against the others.  Carl uses 
all of those little variations profusely... to me its in the very 
essence of REBOL to be optimal and constantly be refined, improved, 
and this usually means by shrinking it in all vectors.  

<end of rant  ;-) >

I agree with you Maxim.

But on the other hand, I never allow my team to sacrifice the readability 
unless IF there is a really good reason to do that AND IF they put 
enough comment WHAT and WHY they do that. Otherwise it wastes our 
time to "solve" the optimisation a few months later.

Optimisations are good / necessary if they are (can be) in loops 
(mostly), but they are dangerous especially if you are writting lower 
level code (mostly C, even Java) because compilers use code-patterns 
to optimize your code, so your hand-optimized code prevents compiler 
optimizations on modern compilers.

And worst, if you are using assembly, your optimizations may prevent 
to use CPU caches and for example when it works faster on one CPU 
it can be even slower than the original version on another CPU.

By the way, I tested on 3 different PC with R2, while loop was always 
faster then the until loop in the above case. Of course I didn't 
test the real case (using do-sql with millions of rows)

And of course Carl should write very optimized code in REBOL because 
everything else is depend on it. 
Hmm I think we should move to another group :)

If I had the same opinion, liquid would still be 10 times slower 
than it is now.


That's big enough to matter, not just measure. I think, that's what 
Gregg pointed out. And remember, there is not a final truth about 
this, as what matters to one person, might not to another.

It doesn't really matter if you get a 133% increase in the speed 
of glass if it has been abandoned for Rebol! lol

My thoughts, too. There's also the matter of why REBOL and AltME 
are such slow memory hogs if Carl's code is so good. The reasons 
are found elsewhere. REBOL systems have aspects of penny wise, pound 
foolish. The actual code needs to be optimised to limit the damage 
a bit

I believe in optimizing on a case by case basis, as most do. And 
I believe in optimizing different things in any given case. Size, 
speed, felxibility, and readability are all fair game for optimization.


As far as AltME and other slow REBOL UIs, I remember Carl saying 
once that View is a miser, saving pennies, while VID is the government 
and spends millions. I think whoever designed the list model used 
in AltMe and other apps (e.g. IOS conference and messenger) chose 
to make the implementation small and quick to write, knowing that 
they might not be fast. They may also not have imagined how far they 
would be pushed.

View is a miser...

 That certainly depends on how you use VID. VIew's SHOW function is 
 a big bottleneck and the most important function of all to optimize 
 for. But yes, AltME lists are rather heavy.

Altme is a slow UI? Just don't make me laugh, those who claim so. 
Have you tried Azureus? That's Java. Altme just runs ok. We all know, 
that the UI is not OS compatible, so there are things to be desired. 
And altme server can run for months without a restart.

The most important thing in optimization is to decide which part 
should be optimized.

If you optimize INSERT, even 0.1%, this gives a huge difference. 
But optimizing something in your INIT function which will be called 
once when the app. start.. I would say don't sacrifice the readablity.

So optimizing core is almost always necessary (like R2/3 function, 
functions in frameworks like LIQUID),

Optimizing the functions in your app. or the app. itself, only if 
it worths.

Maxim: you are mostly talking about the overall performance gain 
in the whole system. But the case above (Cheyenne, do-sql bug) we 
gain 2-3% performance just in do-sql function, IF it's used in a 
millions loop (or returns a few millions of rows) AND only IF you 
use native drivers AND only IF you use /flat refinement. which leads 
very rare cases. So the overall perfornance difference is  very very 
low. (well, still WHILE faster than UNTIL in above case anyway..)

Doc: I've solved "Cheyenne cannot be installed as a service on Windows 
2003 Server" problem.

service.dll requires msvcr71.dll to run, if not present Cheyenne 
crashes with "** Access Error: Cannot open service.dll as library" 
error.

msvcr71.dll file should be present in same folder with service.dll 
or better it should be in %windir%\system32 (or the correct path 
if 64bit OS)
I think we should note this dependency somewhere on the web site.

Right, I should also recompile it with a more recent version of msvcrt 
library I guess.

Its better Cheyenne should write (create) a msvc71.dll if it is not 
already in the same directory. Because when I search for that library 
I see that almost  every program has that dll in their own directory.

Because we cannot trust that the correct version will be in the system 
folder.
OR a better error handling/message for this error  :)

It would at least double the size of the Cheyenne binary, for a feature 
only a few use. I would rather prefer to provide links for downloading 
the right DLL for each Windows version.

You are right, giving a link is better than including the whole dll.

What do you think about making a setup package for Windows? Including 
that dll and some configuration options during the setup, service 
mode default, etc.
If do you think its worth to do, I can do it.

hi all, I am currently building a wrapper for the OpenGL / GLut libraries 
to allow R3 apps to access OpenGL natively.

so far I haven't had any problems with the R3 side of things including 
compiling my own extension with a few new funcs in it...


But now I'm starting to implement the GL specifics and just hit a 
snag.

when Carl adds a few little image! enhancements to the extension 
API, I should be able to use a rebol image! as the interface to get 
the OpenGL render into rebol, using R3 view.  If memcopy works, then 
it should be VERY fast ( a few hundred images/second AFAICT)

(and in a few KBs)

with current cards... why not jump directly to a million cows  :-D

Anton did a 3D GUI demo ... useful for that?

Graham, if it can do what GOBs are doing now, it will be fine for 
VID3.4. It's a matter of how you design the interface, I suppose.

my use for this is to replace VID, for Elixir OS.  which is a fully 
3 dimensional interface design.

I also have a client which needs to visualize genomic data and millions 
of nodes in space.... so this is the first step to getting that contract 
 :-)

I also need the OpenGL performance for a huge art project of mine 
which composites thousands of pictures.

anyways... screenshot in a  few minutes  :-:

Open GL gfx source is mostly  on the C side for now because I'm still 
playing around with the extension and I can't interact with GLut 
or OGL until the extension API is expanded a little bit.

At this point, providing the full capabilities of OpenGL to REBOL 
seems trivial, once the image! improvements are added to Extensions 
API.


Some form of callbacks would also allow us to use a different window 
manager than VID (which would make it faster, since we wouldn't need 
to convert to rebol bitmaps at each frame).

I created this group, cause ever so often these experiments come 
around and we loose them... this should become a quick repository 
of tests & disussion for profiling discoveries we do.


any test should provide the full test command-line code, so its easier 
for other to copy-paste & compare without having to re-type.


ever so often, a compilation should be done, highlighted in a different 
color for easy referral...

probably should add Rebol version and platform in any further profiling 
compilations... to make them even more usefull as a reference.

AS-PAIR and TO-PAIR are mezzanine. Carl has mentioned wanting to 
make AS-PAIR native - sounds like a good candidate.

Gabriele, could be useful to build a GUI like yours to standardize 
our benchmarks.

any one know of a faster method than sorting a block to get the largest 
value inside of it?

in my tests... this:
     forall blk [ val: max val first blk]

is ~ five times SLOWER than this:
     last sort blk

here is a sreen dump of iteration vs maximum-of native use....  goes 
to show the speed difference in binary vs interpreted!!


>> a: [1 1 1 2 2 2 2 2 3 3 3 3 3 4 4 4 4 4 5 5 5 5 5 6 6 6 6 6 7 
7 7 7 7 8 8 8 8 8 9 9 9 9 9 10 10 10 110 110]

report-test  profile :maximum-of reduce [a]
----------------
performed: 10000000 ops within 0:00:09.781 seconds.
speed: 1022390.34863511 ops a second
speed: 34079.678287837 ops a frame
----------------

>> report-test  profile :get-largest reduce [a]
----------------
performed: 10000 ops within 0:00:01.86 seconds.
speed: 5376.34408602151 ops a second
speed: 179.21146953405 ops a frame
----------------

we are talking 190 TIMES faster here

btw


'PROFILE is a handy function I built which accepts ANY function with 
ANY args and repeats the test until it takes longer than one second, 


you can adjust its loop scaling by varying amplitude and magnitude 
of loops at each iteration.


'REPORT-TEST simply dumps human-readable and easy to compare stats 
of calls to profile (which returns a block of info on the test).

actually, you are not sorting or traversing a long serie.
>>reduce [a]
== [[1 1 1 2 2 2 ...]]

your serie contains only one value.

i suggest to do a COPY A instead

but no, the way profile handles its second argument (here reduce 
[a])  is that it uses the second argumet AS the argument spec for 
the function... 

loop i compose/only [ (:func) (args)]

so in the end, the test becomes:

loop i [maximum-of a]

If you are trying to find the largest in a series of not-strictly 
comparable items, then be aware that R2 behaves differently to R3:
     b: reduce [1 none 12-jan-2005 unset 'a copy []]
     last sort b       ;; r2 and r3 agree
     maximum-of  b   ;; r3 has a headache
== [[]]

I'm doing an in-depth analysis of various looping funcs... and discovering 
some VERY unexpected results amongst the various tests... will report 
in a while when I'm done with the various loop use cases.

Yeah, there's often a huge difference between a mezzanine function 
and a native. In R2, FOR is mezz, REPEAT is native.

the comment above about remove-each is false... it was a coding error.

but I'm discovering a lot of discrepancies in things like string 
vs block speed of certain loops... 
and a lot of other neat things like:

pick series 1   

is  15% faster  than

not tail? series

See who is the overall winner in this REBOL iterator slug fest analysis!!!
   

over 8 hours of practically non-stop cpu cycling over a wide variety 
of exit conditions, datasets and ALL iterators in rebol 2 

(loop, repeat, for, forever, foreach, remove-each, forskip, forall, 
while, until )

20 kb of data, statistics, comments and test details.

INVALUABLE data for people wanting to optimize their REBOL code.


http://www.pointillistic.com/open-REBOL/moa/scream/rebol-iterator-comparison.txt

I would a few peer reviews so I can continue to evolve this document 
in order to make it as precise/usefull for everyone.

A thing should be noted.
repeat and foreach do a bind/copy of the evaluated block.

Even if they are the fastest loops, they should be not used too intensivly 
because they will polluate the memory.

It's particularly sensitive for graphics applications or services 
that linger in memory. 


So, that's why  I advise to use only LOOP, WHILE and UNTIL for intensive 
repeated loopings, if you don't want to blow up the memory used by 
your app.

thanks steeve, I'm accumulating all comments

First revision of the benchmarks will include:
	-RAM stats

 -empty vs filled-up loops.  many words and a single func with the 
 same content called from the loop
	-GC de-activated tests + recycle time stats

I did note, that there is a HUGE memory leak which occured probably 
in the actual benchmark procedure itself.


although I keep no reference to any of the data or transient test 
blocks and funcs, they are kept somewhere, and my rebol.exe process 
keeps growing and growing.... I caught it at 500MB !! but it didn't 
do any difference in actual speeds... after a few tests.... cause 
i was a bit scared.

what do you mean ?, it does it here:


>> recycle s: stats loop 1000000 [foreach a [1 2 3][a: a]] print 
stats - s recycle print stats - s
1569504  ;memory allocated by the loop
-320          ; after the recycle

yes, i noticed that too, it's a probem with R2

I think R2 GC can't determine co-dependent unused references... in 
some situations.
ex:
blk: reduce [ a: context [b: none] b: context [c: a] a/b: b ]
blk: none


in this case both a and b point to each other, and clearing blk doesn't 
tell a or b that they aren't used anymore... that is my guess.

I reduce a block which is the test... and since foreach copy/deep, 
and there is NO word ever refering to the content of the refered 
block, I think the contents of the blocks prevent the blocks and 
the data they contain from being collected... 


the block contains words which are not GC counted as zero reference, 
so nothing gets de-allocated...

that's just my guess.

in any case I want to build a single script which does all the tests, 
statistics, and eventually graphics and html pages of all results 
in one (VERY) long process.

so I can better control how the tests are done and prevent automated 
test creation as I am doing now.

Thanks for the info, Maxim. We can do a little deduction from that 
data to guess how REBOL is implemented. The scientific method :)

For instance, 1000 > i would be faster than i < 1000 because ops 
redirect to actions, and actions dispatch based on the type of their 
first argument. If the first argument is a literal value, the action 
of that type can be called directly. If it is a referenced value, 
it woulkd have to be dereferenced first, which is apparently slower.


As for PICK being faster than NOT TAIL?, that is one native compared 
to two, with interpreter overhead between the two. Low-level natives 
like PICK, NOT and TAIL? don't do much in comparison with the interpreter 
overhead. Large numbers of small operations tend to be slower than 
small numbers of large operations, if the amount of work done is 
comparable. This is why structure manipulation is faster in REBOL 
than simple math.

I intend to devote a whole site to these tests eventually.  with 
a very extensive and comprehensive set of test functions and statistics.

you learn a lot by doing it.

with the tests I did, I think I can probably optimise liquid by at 
least 20% just by changing the loops and changing none of the algorithms 
or features.


I am about to create a second reference liquid node type. which will 
be completely compatible from the outside, but with less features 
inside.  I expect to DOUBLE its processing capacity.

yeah amd with the faster fuunction calling in R3 liquid should get 
an immediate boost in speed... it does A LOT of tiny function calls 
to manage the graph as if they where first level types with accessors 
instead of using a controler which loops over the graphs and limits 
flexibility.

if you are willing to keep a version of the keys accessible at run-time, 
then the keyed search algorithm is MUCH faster, but incurs memory 
overhead, and the creation of the keys, on big blocks, is not negligible 
(time not included in tests, but will generally put the keyed algorythm 
slower than the fast-find)

noticed a little discrepancy in results... strange... probably cause 
by a last minute change...

a typical hash (for example is [key1 value1 key2 value2]  .. one 
key, one value