Hey Doug,
Tough qestion. But firstly, have you tried it in Ember and
tested it under load? Are you sure it's not going to be
up to the task? There's lots of other bits in there that
would be a greater chance of being your bottle neck for
performance (e.g. HTTP performance, SQL query performance).
That said, writing your app as a loadable module isn't going
to help a great deal, imho. It'll be the startup overhead
that will be your problem if in fact ember is too slow for
the job.
But, I've written some pretty serious things in Ember and
wasn't let down for performance. You may find that it'll
do the job you need. Putting your code in a library will
help though.
Bambi
..
> -----Original Message-----
> From: owner-msql-list@lists.hughes.com.au
> [mailto:owner-msql-list@lists.hughes.com.au] On Behalf Of Doug Hardie
> Sent: Tuesday, 15 June 2004 7:52 AM
> To: msql-list@lists.hughes.com.au
> Subject: [msql-list] Code design question
>
> I am in the process of developing an app that will be most frequently
> walking through virtually all the records in a large table to
> build an
> HTML table for display. Because this will be used very frequently it
> needs to have the least impact on other functions on that
> processor. I
> can easily build the app as ember scripts. I have a basic version of
> it working that way at this time. It seems like the first
> improvement
> would be to put the critical code in an ember library. That
> would cut
> down the processing time somewhat. However, I believe raw C
> code with
> msql calls is faster yet. So the next logical step would
> seem to be to
> code it in C. However, that means that all the display formatting
> would need to be in the C code also to make the web server
> interface to
> it work. I would like to be able to keep much of the formatting as
> ember scripts so they can be changed as needed. It seems
> like the way
> to do that is to write the code as a dynamic module. That would also
> cut down on the number of forks. However, it would still
> need to make
> many calls to mod_msql. The only way I see to do that is to call the
> underlying routines implementing those calls in mod_msql. It seems
> like that is not a good idea since that interface is likely to change
> over the years.
>
> Any suggestions on the best way to design this?
>
> -----------------------------------------------------------------
> This is the Mini SQL Mailing List operated by Hughes Technologies
> To unsubscribe, go to http://www.Hughes.com.au/extras/email/
>
-----------------------------------------------------------------
This is the Mini SQL Mailing List operated by Hughes Technologies
To unsubscribe, go to http://www.Hughes.com.au/extras/email/
This archive was generated by hypermail 2b30 : Thu Jul 01 2004 - 00:20:00 PDT