Re: Performance

[Tom Wrensch <twrensch@...>]

> On Tue, Nov 06, 2001 at 10:47:08AM -0800, Chris.Kaiser@peoplefirst.com 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