www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - FlowerScirpt teaser

reply bobef <bobef abv_nospam.bg> writes:
Hi guys,

several weeks ago while working on PHP (web based) project of mine I was very
unhappy with PHP's performance. I decided to port the project to D, so I needed
a scripting language for use with D. DMDScript is not free plus it is hell to
extend. I found miniD but it was painfully slow. So I decided to write a new
scripting engine. Now it is more ready than to not, so I want to check if there
is more people interested besides me. If so we could turn this into a community
project or something like that. To be more specific I've almost finished the
engine itself, but it lacks stdlib. And to be a real PHP replacement it needs
very good stdlib (luckily Tango got most of what we need <g>). So please tell
me if there is someone interested in helping to design/implement stdlib and
maybe optimize the engine even further. Here is a little benchmark I did and
some more info about the engine.
The engine is kind of mixture between JavaScript and D. Here is little
something from my readme.txt which is work in progress.

FlowerScript goals:
	As usable for web applications as PHP but faster (done)
	As simple and flexible as JavaScript (done)
	Easily extensible from D (mostly done)
	Embeddable in HTML (done)
	Built in encryption/decryption
	Usable outside web applications
	
I like the simplicity and flexibility of JavaScript, I also like mootools, so I
wanted FlowerScript similar to JavaScript. Instead of documenting everything
(which I will also do if I have the time) I will describe the differences from
JavaScript.
In FS there is no term like "objects" or such. There are two types. Basic data
types: 'boolean', 'string', 'number', 'null', 'undefined', 'void' and 'scopes'.
Scopes are pretty much what JavaScript's objects are. You can put properties in
them. You can use them as associative arrays. In addition scopes can also be
called as functions. The only difference between a scope and a function, is
that the function can accept named arguments. Arrays also derive from 'scope'.
Other differences from JavaScript:
	Array slicing - "array[from..to]" . 'from' or 'to' may be omitted
	Strings can be indexed or sliced as arrays
	Scopes are callable. They act as annonymous functions
	Supports 'outer' keyword to access the outer scope
	Supports some special properties: .dup (duplicate), .dupr (duplicate
recursively), .reverse (reverse array)
	Supports 'foreach' and 'foreachr'. The syntax for both is
"foreach(forexpression) expression|statement", where 'forexpression' must
evaluate to scope (arrays are scopes too). 'key' and 'value' are automatically
defined (with these names) withing the foreach's scope
	No support for the following statements (this may change in future):
		in - not as flexible as foreach
		switch - it is useless as it does nothing more than if/else but with
inconsistent syntax
		do, while - 'for' without semicolons will do the same as while. i.e.
for(condition) instead of for(init;condition;dosomething)
		new, delete - to delete a variable use symbol=undefined;
		try, catch, finally - not implemented yet
	Supports 'goto'. The difference from C is that labels are not "label:" but
"label expression;", where 'expression' is expression that evaluates to string.
This seems more consistent and flexible.
	All variables but numbers are passed by reference instead of copy. Numbers are
always copied.
	Other minor things to be added later...
They may be other differences since I haven't studied the ECMAScript
specifications...

Little benchmark:

FlowerScript (development version -O -inline) versus PHP 5.2.3 with
ZendOptimizer 3.2.8 (zend_optimizer.optimization_level=15)
Benchmarks are on the same PC
PHP timing is done with microtime(), which means that this timing DOES NOT
INCLUDE THE COMPILATION TIME, unlike FlowerScript which is summary of
compilation (without caching) and execution.


Tests:

================================================

///////////
///Flower (time ranges from 0.017 to 0.016)
///////////

$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 />");
}


///////////
///PHP (time ranges from 0.9 to 0.1, generally above 0.3)
///////////

<?php
$a=microtime();
$SERVER=array("gosho"=>"pesho");$COOKIE=array("gosho"=>"pesho");
for($c=0;$c<=1000;$c++)
{
	$a=("gosho"."[".$SERVER["gosho"]."]"."=".$SERVER["gosho"]."<br />");
	$b=("gosho"."[".$COOKIE["gosho"]."]"."=".$COOKIE["gosho"]."<br />");
}
echo(microtime()-$a);
?>


================================================

So if you are interested give me a note and I will eventually start a dsource
project.
Sep 25 2007
next sibling parent Lester Martin <Lester ewam-associates.com> writes:
I would love to use for my webpage as soon as I have added every little feature
my webpage needs.
bobef Wrote:


 Hi guys,
 
 several weeks ago while working on PHP (web based) project of mine I was very
unhappy with PHP's performance. I decided to port the project to D, so I needed
a scripting language for use with D. DMDScript is not free plus it is hell to
extend. I found miniD but it was painfully slow. So I decided to write a new
scripting engine. Now it is more ready than to not, so I want to check if there
is more people interested besides me. If so we could turn this into a community
project or something like that. To be more specific I've almost finished the
engine itself, but it lacks stdlib. And to be a real PHP replacement it needs
very good stdlib (luckily Tango got most of what we need <g>). So please tell
me if there is someone interested in helping to design/implement stdlib and
maybe optimize the engine even further. Here is a little benchmark I did and
some more info about the engine.
 The engine is kind of mixture between JavaScript and D. Here is little
something from my readme.txt which is work in progress.
 
 FlowerScript goals:
 	As usable for web applications as PHP but faster (done)
 	As simple and flexible as JavaScript (done)
 	Easily extensible from D (mostly done)
 	Embeddable in HTML (done)
 	Built in encryption/decryption
 	Usable outside web applications
 	
 I like the simplicity and flexibility of JavaScript, I also like mootools, so
I wanted FlowerScript similar to JavaScript. Instead of documenting everything
(which I will also do if I have the time) I will describe the differences from
JavaScript.
 In FS there is no term like "objects" or such. There are two types. Basic data
types: 'boolean', 'string', 'number', 'null', 'undefined', 'void' and 'scopes'.
Scopes are pretty much what JavaScript's objects are. You can put properties in
them. You can use them as associative arrays. In addition scopes can also be
called as functions. The only difference between a scope and a function, is
that the function can accept named arguments. Arrays also derive from 'scope'.
 Other differences from JavaScript:
 	Array slicing - "array[from..to]" . 'from' or 'to' may be omitted
 	Strings can be indexed or sliced as arrays
 	Scopes are callable. They act as annonymous functions
 	Supports 'outer' keyword to access the outer scope
 	Supports some special properties: .dup (duplicate), .dupr (duplicate
recursively), .reverse (reverse array)
 	Supports 'foreach' and 'foreachr'. The syntax for both is
"foreach(forexpression) expression|statement", where 'forexpression' must
evaluate to scope (arrays are scopes too). 'key' and 'value' are automatically
defined (with these names) withing the foreach's scope
 	No support for the following statements (this may change in future):
 		in - not as flexible as foreach
 		switch - it is useless as it does nothing more than if/else but with
inconsistent syntax
 		do, while - 'for' without semicolons will do the same as while. i.e.
for(condition) instead of for(init;condition;dosomething)
 		new, delete - to delete a variable use symbol=undefined;
 		try, catch, finally - not implemented yet
 	Supports 'goto'. The difference from C is that labels are not "label:" but
"label expression;", where 'expression' is expression that evaluates to string.
This seems more consistent and flexible.
 	All variables but numbers are passed by reference instead of copy. Numbers
are always copied.
 	Other minor things to be added later...
 They may be other differences since I haven't studied the ECMAScript
specifications...
 
 Little benchmark:
 
 FlowerScript (development version -O -inline) versus PHP 5.2.3 with
ZendOptimizer 3.2.8 (zend_optimizer.optimization_level=15)
 Benchmarks are on the same PC
 PHP timing is done with microtime(), which means that this timing DOES NOT
INCLUDE THE COMPILATION TIME, unlike FlowerScript which is summary of
compilation (without caching) and execution.
 
 
 Tests:
 
 ================================================
 
 ///////////
 ///Flower (time ranges from 0.017 to 0.016)
 ///////////
 
 $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 />");
 }
 
 
 ///////////
 ///PHP (time ranges from 0.9 to 0.1, generally above 0.3)
 ///////////
 
 <?php
 $a=microtime();
 $SERVER=array("gosho"=>"pesho");$COOKIE=array("gosho"=>"pesho");
 for($c=0;$c<=1000;$c++)
 {
 	$a=("gosho"."[".$SERVER["gosho"]."]"."=".$SERVER["gosho"]."<br />");
 	$b=("gosho"."[".$COOKIE["gosho"]."]"."=".$COOKIE["gosho"]."<br />");
 }
 echo(microtime()-$a);
 ?>
 
 
 ================================================
 
 So if you are interested give me a note and I will eventually start a dsource
project.
Sep 25 2007
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"bobef" <bobef abv_nospam.bg> wrote in message 
news:fdbs6o$r06$1 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.


 $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?
Sep 25 2007
parent reply bobef <bobef abv_nospam.bg> writes:
Jarrett Billingsley Wrote:


 "bobef" <bobef abv_nospam.bg> wrote in message 
 news:fdbs6o$r06$1 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...
Sep 26 2007
next sibling parent bobef <bobef abv_nospam.bg> writes:
bobef Wrote:


It would be nice if you post some benchmarks.


I mean comparisons to other languages.
Sep 26 2007
prev sibling next sibling parent bobef <bobef abv_nospam.bg> writes:
I felt bad I accusing MiniD in slowness so I did the same test with MiniD from
trunk and it is actually faster. This example takes 7.5 millisecs on my PC.

D:

import tango.text.Util;
import tango.io.File;

import minid.minid;
import minid.types;

void main()
{
	auto a=new tango.util.time.StopWatch.StopWatch;
	a.start();
	auto context = NewContext();
	scope auto f=new File("test.md");
	dchar[] buf=tango.text.convert.Utf.toUtf32(cast(char[])f.read());
	loadModuleString(context.mainThread,buf,null,"test.md");
	tango.io.Console.Cout("\n\n\n"~tango.text.convert.Float.toUtf8(a.stop()));
}

MiniD:

module test;

global SERVER={gosho="pesho"};
global COOKIE={gosho="pesho"};
for(local c=0;c<=1000;c++)
{
        local a=("gosho"~"["~SERVER["gosho"]~"]"~"="~SERVER["gosho"]~"<br />");
        local b=("gosho"~"["~COOKIE["gosho"]~"]"~"="~COOKIE["gosho"]~"<br />");
}
Sep 26 2007
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"bobef" <bobef abv_nospam.bg> wrote in message 
news:fdd020$plv$1 digitalmars.com...


 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, as I explained on the threads on the MiniD forum, exactly what 
MiniD already does.  (And yes, it's also quite fast.)
Sep 26 2007
prev sibling next sibling parent reply Alexander Panek <a.panek brainsware.org> writes:
bobef wrote:

 Hi guys,
 
 several weeks ago while working on PHP (web based) project of mine I was very
unhappy with PHP's performance. I decided to port the project to D, so I needed
a scripting language for use with D. DMDScript is not free plus it is hell to
extend. I found miniD but it was painfully slow. So I decided to write a new
scripting engine. Now it is more ready than to not, so I want to check if there
is more people interested besides me. If so we could turn this into a community
project or something like that. To be more specific I've almost finished the
engine itself, but it lacks stdlib. And to be a real PHP replacement it needs
very good stdlib (luckily Tango got most of what we need <g>). So please tell
me if there is someone interested in helping to design/implement stdlib and
maybe optimize the engine even further. Here is a little benchmark I did and
some more info about the engine.
 The engine is kind of mixture between JavaScript and D. Here is little
something from my readme.txt which is work in progress.


I'd rather dig into MiniD and help improve the performance than creating 
a new scripting engine. Code duplication for a language that has PHP's 
limitations just isn't worth anything, IMHO. *shrug*
Sep 25 2007
parent reply bobef <bobef abv_nospam.bg> writes:
Alexander Panek Wrote:


 Code duplication for a language that has PHP's 
 limitations just isn't worth anything, IMHO. *shrug*


I agree and I am not creating language that has PHP's limitations. PHP is great
for the web because it it has great stdlib and is easy to embed, but as
programming language (IMO) it sucks. FlowerScript is not PHP. It is more like a
JavaScript + some D features - some features I find useless + few small changes
of my own. So it is very dynamic, like JavaScript and unlike PHP. Sorry if I am
not using the right terms here, I hope you understand what I mean when I say
"dynamic".
Sep 26 2007
parent reply Alexander Panek <a.panek brainsware.org> writes:
Well, even the fact that it seems to use the dollar sign as variable 
prefix makes me go puke. Really. There are so many good languages out 
there, why do you need create a new, incompatible and most probably 
unsupported one? Rather use MiniD, Ruby, Python, or what not else, as 
they are actively developed and not just a small hack to get some more 
performance for a website.
Sep 26 2007
next sibling parent reply Henning Hasemann <hhasemann web.de> writes:
Alexander Panek <a.panek brainsware.org> wrote:

 Well, even the fact that it seems to use the dollar sign as variable 
 prefix makes me go puke. Really. There are so many good languages out 
 there, why do you need create a new, incompatible and most probably 
 unsupported one? Rather use MiniD, Ruby, Python, or what not else, as 
 they are actively developed and not just a small hack to get some
 more performance for a website.
 


If performance plays an important role, I wonder why nobody mentioned
lua. (I did never really work with it but some voices say its quite
fast, flexible and extensible with 'native code').

Also I have the feeling lots of people inseperable connect web
programming with scripting languages.

I see no real reason for not using plain D, maybe with a well-thought
web-framework/library for web-apps. I mean especially web-apps require
a good performance and if you remember that still lot of apps use CGI
it is gruesome to re-load an interpreter every request.

(I know there are lots of coutermeasures you can take against this
problem, I just wanted to show the extreme case)

Concerning security there ARE good reasons why you wouldnt want to
write your webapp in C++ or C, you almost pre-programmed buffer
overflows then. But D is lots more secure by design and if you look at
PHP, you see that a scripting host does not always liberate you from
buffer-overflows or other attacks.

I would love such a framework. I'm also wondering if there might be a
way to avoid that awful stateless coding style, ie to be able to do
something like:

----
ask_for_users_address();
// user gets a form to enter its address, program here is "frozen" here
// until the user submits or the session times out

ask_for_users_bank_account();
// present another form
----

Henning

-- 
GPG Public Key:
http://keyserver.ganneff.de:11371/pks/lookup?op=get&search=0xDDD6D36D41911851
Fingerprint: 344F 4072 F038 BB9E B35D  E6AB DDD6 D36D 4191 1851
Sep 26 2007
next sibling parent reply "Vladimir Panteleev" <thecybershadow gmail.com> writes:
On Wed, 26 Sep 2007 13:11:00 +0300, Henning Hasemann <hhasemann web.de> wrote:


 I would love such a framework. I'm also wondering if there might be a
 way to avoid that awful stateless coding style, ie to be able to do
 something like:

 ----
 ask_for_users_address();
 // user gets a form to enter its address, program here is "frozen" here
 // until the user submits or the session times out

 ask_for_users_bank_account();
 // present another form
 ----


It should be possible with threads or fibers. Threads consume OS resources, so
they may not be the perfect choice (consider the DoS attack scenario). If you
don't allocate too much resources per thread/fiber (stack space, but not much
is necessary here - just enough to control the state of a session), it might
even be practically useable with some tuning.

-- 
Best regards,
 Vladimir                          mailto:thecybershadow gmail.com
Sep 26 2007
parent kenny <funisher gmail.com> writes:
Vladimir Panteleev wrote:

 On Wed, 26 Sep 2007 13:11:00 +0300, Henning Hasemann <hhasemann web.de> wrote:
 

 I would love such a framework. I'm also wondering if there might be a
 way to avoid that awful stateless coding style, ie to be able to do
 something like:

 ----
 ask_for_users_address();
 // user gets a form to enter its address, program here is "frozen" here
 // until the user submits or the session times out

 ask_for_users_bank_account();
 // present another form
 ----


 
 It should be possible with threads or fibers. Threads consume OS resources, so
they may not be the perfect choice (consider the DoS attack scenario). If you
don't allocate too much resources per thread/fiber (stack space, but not much
is necessary here - just enough to control the state of a session), it might
even be practically useable with some tuning.
 


This is extremely difficult to do. The simple answer is, it's difficult to
ensure that the user will get the same server in the second request. Also, if
that server fails, what happens? I suppose the data for the address is lost,
however that's not what you want. Machines fail. Also, if you MUST have the
machine online, then you can't ever take the machine offline to do upgrades,
reconfiguration or whatever. Take the example of google. They expect machines
to fail, and implement failover in the software that they write -- bigtable and
such.

I have written web frameworks in D -- with MVC and stuff, and it's very fast.
It's not a scripting language, because all of the data work is done inside of D
objects. IMO, it'd just be another MVC framework, until I write the portion
that allows for automatic failover, distributed processing, and ways to
implement intelligent caching and concurrency.

For example. I work for a web page that generates millions of page views a day.
We run php, mysql, memcache. We have 4 php servers, and 8 DB servers. During
peak, our php servers easily have a concurrency of over 100 processes
simultaneously -- yet only 4% CPU usage. However, our DB servers have about 30
thread concurrency and about 600% CPU usage. (8 core machines).

We will never ever optimize php, because it spends only about 10-40ms inside of
php and the rest at memcache and the DB servers. You can optimize D all you
want, or even run your website in a C daemon, but most websites struggle
because they have database problems.. Data grows exponentially, even with
linear user growth, and becomes a huge problem, beacuse the database will grow
larger than the memory of the machine, and can never distribute the query among
multiple machines.

Personally, a D implementation of web specific distributed computing such as a
bigtable implementation would be a whole lot more effective, and would actually
begin to achieve the desire of the stateless computing better than threads or
fibers ever could.

Just my 2 cents

Kenny
Sep 26 2007
prev sibling parent Tomas Lindquist Olsen <tomas famolsen.dk> writes:
There is FastCGI4D. This fits the bill pretty well. I've never coded for
fcgi, but from what I've heard it's the way to go. It uses Tango.

http://dsource.org/projects/fastcgi4d/
Sep 26 2007
prev sibling parent reply BLS <nanali nospam-wanadoo.fr> writes:
Alexander Panek schrieb:

 Well, even the fact that it seems to use the dollar sign as variable 
 prefix makes me go puke. Really. There are so many good languages out 
 there, why do you need create a new, incompatible and most probably 
 unsupported one? Rather use MiniD, Ruby, Python, or what not else, as 
 they are actively developed and not just a small hack to get some more 
 performance for a website.
 


IMO Ruby is not an option because 1) Ruby is too slow. 2) Ruby is not 
really extendable from D.
Speed matters!
I agree, the dollar sign is ugly. I guess it exists to speed up parsing.
Bjoern
Sep 26 2007
next sibling parent bobef <bobef abv_nospam.bg> writes:
BLS Wrote:


 Alexander Panek schrieb:

 Well, even the fact that it seems to use the dollar sign as variable 
 prefix makes me go puke. Really. There are so many good languages out 
 there, why do you need create a new, incompatible and most probably 
 unsupported one? Rather use MiniD, Ruby, Python, or what not else, as 
 they are actively developed and not just a small hack to get some more 
 performance for a website.
 


 IMO Ruby is not an option because 1) Ruby is too slow. 2) Ruby is not 
 really extendable from D.
 Speed matters!
 I agree, the dollar sign is ugly. I guess it exists to speed up parsing.
 Bjoern


No! Dollar sign is one of the worst features of PHP IMO and I would never do
that. The dollar sign is for compatibility with JavaScript. Is is NOT required
it is just a valid identifier character and it is there because I wrote the
benchmark in php first and copied it to flowerscript :)
Sep 26 2007
prev sibling parent reply Alexander Panek <alexander.panek brainsware.org> writes:
BLS Wrote:

 IMO Ruby is not an option because 1) Ruby is too slow. 2) Ruby is not 
 really extendable from D.


1) Ruby isn't so slow as most people want it to be.
2) Ruby is extendable from C, thus easily extendable from D.
Sep 26 2007
parent reply 0ffh <spam frankhirsch.net> writes:
Alexander Panek wrote:

 1) Ruby isn't so slow as most people want it to be.


Whoever might /want/ Ruby to be slow (apart from GvR and LW)? :)
More important is, IMHO, that execution speed is not everything.
It just needs to be fast enough to do the job, and often it is.

Regards, Frank
Sep 26 2007
parent reply Alexander Panek <a.panek brainsware.org> writes:
0ffh wrote:

 Alexander Panek wrote:

 1) Ruby isn't so slow as most people want it to be.


 
 Whoever might /want/ Ruby to be slow (apart from GvR and LW)? :)
 More important is, IMHO, that execution speed is not everything.
 It just needs to be fast enough to do the job, and often it is.


Exactly! As mentioned before in this thread: in most cases the database 
is a lot slower than the Ruby application - let alone when you run it on 
a quad core Xeon with 20 Mongrels or so. *shrug* :P
Sep 26 2007
parent eao197 <eao197 intervale.ru> writes:
On Wed, 26 Sep 2007 23:41:27 +0400, Alexander Panek  
<a.panek brainsware.org> wrote:


 0ffh wrote:

 Alexander Panek wrote:

 1) Ruby isn't so slow as most people want it to be.


  Whoever might /want/ Ruby to be slow (apart from GvR and LW)? :)
 More important is, IMHO, that execution speed is not everything.
 It just needs to be fast enough to do the job, and often it is.


 Exactly! As mentioned before in this thread: in most cases the database  
 is a lot slower than the Ruby application - let alone when you run it on  
 a quad core Xeon with 20 Mongrels or so. *shrug* :P


There is an interesting presentation about really large Web-applications  
and Ruby:  
http://jxh.bingodisk.com/bingo/public/presentations/JHoffmanRailsConf-Berlin-Sept2007.pdf

-- 
Regards,
Yauheni Akhotnikau
Sep 26 2007
prev sibling parent reply Alexander Panek <alexander.panek brainsware.org> writes:
Oh.. what I've forgotten to ask: what's the license?
Sep 26 2007
parent bobef <bobef abv_nospam.bg> writes:
Alexander Panek Wrote:


 Oh.. what I've forgotten to ask: what's the license?


Well if there is I license it will be BSD or something. But from what I can
tell there is no much interest here plus I am looking at MiniD again. It seems
it is quite fast and the reason I thought it was slow was just its writef
function. I will run some more tests in real apps and if MiniD turns more
efficient I may end up using it. Although my script is almost finished, MiniD
is fully finished which makes it the easier way :)
Sep 27 2007