FlowerScirpt teaser

[bobef]

Jarrett Billingsley Wrote:

> "bobef" <bobef at abv_nospam.bg> wrote in message 
> news:fdbs6o$r06$1 at digitalmars.com...
> > I found miniD but it was painfully slow.
> 
> Now, that's not entirely fair because I _did_ reply to your threads and 
> offer suggestions (such as compiling with -release, which, BTW, about halves 
> the execution time for the example you gave), but as far as I can tell you 
> never even looked at them again.  I've also been working on speeding up the 
> interpreter, mostly because of your (and others') complaints.
> 

I am sorry it looks like that. I've read all your answers in the threads back then, but I haven't looked at the MiniD after I decided to write engine from scratch. I believe you did improvements and maybe it is faster now. It would be nice if you post some benchmarks. But back then, the benchmark I did took 50milisecs for 100 loops (optimized and inlined) and mine takes 17milisecs for 1000 loops with more concats. By the way I have different PC now (it is almost the same as the old one but just for the record)... Sorry, I shouldn't have said "painfully slow", because it isn't really that slow. What I meant is "slower than my needs require".


> > $SERVER={"gosho":"pesho"};$COOKIE={"gosho":"pesho"};
> > for($c=0;$c<=1000;$c++)
> > {
> > $a=("gosho"~"["~$SERVER["gosho"]~"]"~"="~$SERVER["gosho"]~"<br />");
> > $b=("gosho"~"["~$COOKIE["gosho"]~"]"~"="~$COOKIE["gosho"]~"<br />");
> > }
> 
> I'd like to know how FlowerScript handles strings.  Are they mutable?  And 
> if not, how do you get around the problem of allocating (at a bare minimum) 
> 2000 strings in this loop? 
> 
> 

I don't know what is "mutable", sorry for my poor English. The only mutable thing that I know is my sound card :D I will try to explain, though.
I do compile time optimizations that "sees" that there are several concats (or any other binary operator) in a row so instead of creating several new string objects it creates only one. Furthermore the cat operator counts the length of the resulting string (or array) and does only one allocation, so I haven't profiled it (yet) but in these loop there are like 2 allocations times 1000... This is 2000 allocations and another 2000 .dup-s... I guess D is fast :D This is all I do and can remember of... I will release the source soon, which is less than 100k at the moment, and you will see for yourself if you are interested. I guess the reason it being relatively fast is because the whole engine is some kind lightweight...