Re: use LL(1) or LALR(1) for JavaScript SQL interpreter?

"Eric" <englere_geo@yahoo.com>
15 Nov 2006 00:12:30 -0500

          From comp.compilers

Related articles
use LL(1) or LALR(1) for JavaScript SQL interpreter? petermichaux@gmail.com (Peter Michaux) (2006-11-11)
Re: use LL(1) or LALR(1) for JavaScript SQL interpreter? englere_geo@yahoo.com (Eric) (2006-11-11)
Re: use LL(1) or LALR(1) for JavaScript SQL interpreter? petermichaux@gmail.com (Peter Michaux) (2006-11-13)
Re: use LL(1) or LALR(1) for JavaScript SQL interpreter? JustinBl@osiristrading.com (excalibur2000) (2006-11-15)
Re: use LL(1) or LALR(1) for JavaScript SQL interpreter? englere_geo@yahoo.com (Eric) (2006-11-15)
| List of all articles for this month |

From: "Eric" <englere_geo@yahoo.com>
Newsgroups: comp.compilers
Date: 15 Nov 2006 00:12:30 -0500
Organization: Compilers Central
References: 06-11-05006-11-056
Keywords: parse, SQL
Posted-Date: 15 Nov 2006 00:12:30 EST

Peter Michaux wrote:
> Do you have an example that shows this slowness? I haven't experienced
> this. I would like to see this in action to prove it is a bad idea.


JavaScript, and most interpreters, are 10-50 times slower than native
compiled code, and a simple test will reveal this. I suppose a highly
optimum interpreter could possibly be only 5 times slower but you're
not likely to see something that advanced in a web browser.


You also have to add the long page load times if you'll be sending a
lot of data to the browser for aggregation.


> > You'll also see a lot of errors if you really push the limits.
>
> Which error messages?


First, you'll overflow your response buffer, assuming you have it
enabled in your server. If you disable it to avoid the problem you
won't be able to handle many simultaneous requests.


Then your browser will reach it's resource limits and you'll see some
very interesting, but meaningless errors to that effect.


> > Why not keep the data on the server and query it from the browser?
>
> It might not be my decision. I agree with you however.


We all had to make the change in our thinking to migrate from a
traditional server-centric world to a web model with servers and
browsers. You have to adapt to the model - this is NOT really a
distrbuted computing model. The only thing that works well in a browser
is UI support code. Browsers can not perform any heavy lifting.


Just grab a small benchmark and show them how slow it is. Go here and
do a View Source to see the code. Then port this to a C compiler and
run the test that way:


http://www.rahul.net/rhn/bench.js.html


You should learn PHP and MySQL, or something else along those lines.
PHP is a database-friendly scripting language that has seen exponential
growth in recent years. MySQL is free, and fast. This is an easy
solution for you once you get your head around it. If you'll be doing a
lot of this kind of work, you can look at other web technologies, as
needed. I'm not prejudiced - we use ASP.NET heavily, but PHP is the
best for a small job that has to be done soon. Remember that the
scripting language is only for glue code and the hard work will be done
by the DBMS.


The biggest reason to use a "canned" DBMS is that you can complete the
job in a few weeks. Compare this to coding your own database in
JavaScript, which will take months and yield poor performance.


Eric


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.