Diamond speed issues (was: OOP libraries (was: Multiple includes
C. K. Lester wrote: > <snip>
> By "quite slow," do you mean by hundredths of a second over the course
> of one million iterations? or what? And that's all relative. For basic
> tasks, I'm sure it will be fast enough on a reasonably equipped rig.
Quite fast enough.
A Diamond method call takes about 6 times as long as a pure Eu function call
as 25000 iterations, rising gradually to 12 times at 250000 iterations, then
staying fairly level. This is using a reference method that makes two calls
to a do-nothing function. The more work a method does, the less relevant
the overhead becomes. With 250000 complex database updates, the speed
disadvantage would be only a few percent.
Object creation is the most impacted, as the object values are stored in a
single long sequence. If Eu had built-in references, I could reduce the
object creation overhead considerably.
The Diamond designer can work around the speed limitations in several ways.
1. When reading a property, assign its value to a local variable, don't read
it repeatedly within a method.
2. Minimize object creation--if your program uses many objects but only a
fraction of in use at any one time, recycle used objects.
3. Use methods for an object's core functionality--implement details as pure
Eu routines called by the methods rather than other methods whenever
possible.
Numbers 1 and 2 are useful in any OO language, number 3 is illegal in
most--but this technique gains a huge speed advantage over Python or Ruby.
-- Mike Nelson
|
Not Categorized, Please Help
|
|
