1. 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
2. Re: Diamond speed issues (was: OOP libraries (was: Multiple includes
On Wed, 12 Nov 2003 07:29:57 -0800, Mike Nelson
<MichaelANelson at WORLDNET.ATT.NET> wrote:
>If Eu had built-in references, I could reduce the object creation overhead
>considerably.
Not quite sure what you mean by that. variable_id()? pointers?
Pete
http://palacebuilders.pwp.blueyonder.co.uk/euphoria.html
3. Re: Diamond speed issues (was: OOP libraries (was: Multiple includes
Pete Lomax wrote:
> Mike Nelson wrote:
>
> >If Eu had built-in references, I could reduce the object creation
overhead considerably.
>
> Not quite sure what you mean by that. variable_id()? pointers?
>
Exactly, with the ability to create variables on the fly. Then each object
could be its own variable, accessed via variable_id().
I believe someone wrote an interpreter with this feature?
-- Mike Nelson
4. Re: Diamond speed issues (was: OOP libraries (was: Multiple includes
On 12 Nov 2003, at 8:50, Mike Nelson wrote:
>
>
> Pete Lomax wrote:
>
> > Mike Nelson wrote:
> >
> > >If Eu had built-in references, I could reduce the object creation
> overhead considerably.
> >
> > Not quite sure what you mean by that. variable_id()? pointers?
> >
> Exactly, with the ability to create variables on the fly. Then each object
> could be its own variable, accessed via variable_id().
See "associated lists", Jiri did one. Then to run code contained in a variable,
see eval() in Bach.
Kat
5. Re: Diamond speed issues (was: OOP libraries (was: Multiple includes
Kat wrote:
>See "associated lists", Jiri did one. Then to run code contained in a variable,
>
>see eval() in Bach.
>
>Kat
>
>
I was lookin' at that the other day but couldn't figure which one to
download. He's got several on his page. Which one is the latest 'n'
greatest? Do they all serve a different purpose?
6. Re: Diamond speed issues (was: OOP libraries (was: Multiple includes
- Posted by kbochert at copper.net
Nov 12, 2003
On 12 Nov 2003 at 11:49, C. K. Lester wrote:
>
>
> Kat wrote:
>
> >See "associated lists", Jiri did one. Then to run code contained in a
> >variable,
> >see eval() in Bach.
> >
> >Kat
> >
> >
> I was lookin' at that the other day but couldn't figure which one to
> download. He's got several on his page. Which one is the latest 'n'
> greatest? Do they all serve a different purpose?
>
It is a little short on explanation.
Bach 1.4.6 is my original release, no longer being developed.
Bach 2.1.3 is the latest. It departs from Euphoria a little more.
Some improvements in 2.1 (IMO)
1) It is possible to define blocks like C ('{}') or like Python (indent)
2) '?' has log (print to file) and regess (compare against file) modes
3) a 'def' is a function whose return value can be ignored
4) a 'coroutine' is a def that begins where it last returned -- local variables
are preserved across invocations.
5) 'import' includes a file only in the current file.
6) lists may be used in formal parameters "function foo (integer x, y, z)"
7) string datatype
8) A default argument is permitted, as in:
function foo (string s, integer flag = 0)
...
end function
foo("test")
The next update is intended to have "eval()" to run a piece of
Bach code. I have it running, but have found a small memory
leak (thanks, Kat) that will require major surgery to remove.
Karl Bochert
