lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Well, there was to be a background service monitoring the
db for changes to the rules, that would preform the compilation.
Then the resulting .dll would be pushed to a dir. There would
be a history of three dlls, and a periodic update of like 15 minutes.

So it wouldn't impact the clients. I was just hoping of outputing
lua script instead of the dlls.. but I guess, there would still be
unloading as you'd have to refresh the lua state? 

Hmmm.. sorry for being only marginally on topic. 


> -----Original Message-----
> From: Tom Wrensch []
> Sent: Tuesday, November 06, 2001 11:40 AM
> To: Multiple recipients of list
> Subject: Re: Performance
> > On Tue, Nov 06, 2001 at 10:47:08AM -0800, 
> wrote:
> > > One good reason why, and one that I need, is to convince 
> management
> > > that its a worthy solution to some dynamic code 
> generation problems.
> > > 
> > > My boss wants me to generate compiled C++ on the fly based on the
> > > user communities mods. 
> > 
> > Okay. I presume this is for performance reasons?
> > 
> > > We're to build a series of tools to enable the user community to
> > > change the business rules on the fly. I'd like for these 
> rules to be
> > > generated in lua and parsed from our C++ engine.  But I need to
> > > convince him that it will be fast enough.
> I did something similar to this for a large insurance 
> company. We rolled
> our own language, a solution that made sense at the time. We 
> would have
> saved a lot of time/effort if Lua had been available (this was 1993 or
> so). It has all the capabilities we needed and is much faster 
> than our own
> solution. Certainly if I had to do it again I would use Lua.
> I certainly would never have recommended creating compiled 
> modules in 'C'
> or some such language! Not only is it a much more difficult 
> solution to
> implement (and a nightmare to debug and maintain), but the performance
> issues are incredibly complex. How large are these modules? 
> How often are
> they loaded/reloaded? Do changes have to take effect 
> dynamically? If so
> how will that be handed? What about the cost of recompilation, C++
> compilers are not exactly easy on the processor. If you wish 
> I will state
> my reservations to your management officially. (I look good on paper).
> It may not relate, but when we rolled our own language at the 
> insurance
> company, we too were origionally worried about performance. 
> As it turned
> out the performance issues were dominated by database access/data
> communication times -- CPU usage made almost zero difference. In this
> situation the compiled module solution would be SLOWER 
> because the modules
> will almost certainly be larger than the equivalent Lua bytecodes.
> Sorry, this is only marginally on-topic.
>   - Tom Wrensch