OpenEuphoria

Re: Structures; etc.

• Posted by Irv Mullins <irv at ELLIJAY.COM> Jan 30, 2000
• 497 views

On Sun, 30 Jan 2000, JJ wrote:
> EU>On Sun, 30 Jan 2000, Irv wrote:

> EU>You can see that user-defined types are useless except for debugging
> purpose
> EU>as the overhead kills any performance whatsoever.  This is for a single
> type
> EU>check. I haven't even tried nested type checks. Any pre-processor would
> eith
> EU>have to let everything go untyped, or rely on the type() function. Neither
> i
> EU>acceptable. This functionality needs to be built into the language itself.
>
> EU>Irv
>
> How would building object-orientation into the interpreter make this go
> faster? A pre-processor could be smart, and not do unnessicary type
> checking. For example:

No one said object-orientation would make it faster. I don't even like
OOP. What I said was, if Euphoria typed checked variables
_wherever_ they were, using internal  type checking functions, we would gain
safety with very little loss in speed. This has not related to OOP.

> type sequenceOfIntegers(object x)
>         if sequence(x) then
>                 for i = 1 to length(x) do
>                         if not integer(x[i]) then
>                                 return 0
>                         end if
>                 end for
>                 return 1
>         end if
>         return 0
> end type
>
> class MyClass
>         sequenceOfIntegers seq1
>         sequenceOfIntegers seq2
>         sequenceOfIntegers seq3
>         sequenceOfIntegers seq4
>         sequenceOfIntegers seq5
> end class
>
> MyClass instance
> instance.seq1 = repeat(0,100000)
> instance.seq2 = instance.seq1
> instance.seq3 = instance.seq1
> instance.seq4 = instance.seq1
> instance.seq5 = instance.seq1
> instance.seq5[50] = 1000
>
> A smart pre-processor could optomize see that:
> 1. When instance.seq1 and instance.seq5[50] are assigned, there is no need to
> check everything else.

A smart pre-processor might see it, but it couldn't do anything about it
without passing it thru your type() function. If user type checking one value
takes 9x as long as a similar built-in integer check, just imagine how long
that nested check it going to take. Worse, what if the array is not of a
built-in type - perhaps it's an array of coordinates, for example. Then your
type check loop has to call _another_ user defined type check. Nap time!

 > 2. When instance.seq2-5 are assigned,there is no need to check them
> because instance.seq1 is the same type and they're ok >

Nope. Suppose I change something in seq2. In fact, why would I even declare
5 sequences of integers _unless_ I planned to change the contents? Might as
well use one. It's when assignments are made that the type checking must come
into play.

 > In your example, a smart pre-processor could see that 5 is a byte,
and  therefore x doesn't need to be checked 10000000. In fact, an even
smarter pre-processor could optomize the code to: >
> byte x
> atom start
> start = time()
> x = 5
> ? time()-start

Sure. But what if that line was x = z   ?
z might be almost anything. Who knows, each time it might be different.
Unless your pre-processor is psychic, I don't think it's going to be able to
simplify things very much.

Irv - busy inventing the Prophetic Pre-Processor.