OpenEuphoria

Re: Optimization

• Posted by Robert Craig <rds at RapidEuphoria.com> Feb 09, 2006
• 422 views

Jason Gade wrote:
> I know I've brought this up before, but I want to ask again.
> 
> Does Euphoria optimize read-modify-write situation?
> 
> I know that internally Euphoria passes by reference and only allocates a new
> sequence if elements are modified.
> 
> But does the interpreter recognize the following:
> }}}
<eucode>
> sequence foo
> foo = bar(foo)
> </eucode>
{{{

> 
> Is this optimized as a pattern where foo itself can be modified instead of
> allocating
> and returning a new sequence?
> 
> Recognizing this optimization may be difficult, but I think that it would be
> very useful. I suppose where the variable are foo[1] or foo[1][2] or whatever
> would make things even more difficult. Maybe just for top-level references?
> 
> Of course you could also have:
> }}}
<eucode>
> sequence foo
> foo = bar(baz, x, y, z, fun(foo), foo[1..a], d, foo, i, j)
> </eucode>
{{{

> 
> Which would be truly horrid, but still...
> 
> If Euphoria does this automatically it should be in the docs.

I've discussed this before.
No, I don't do this optimization,
but I have it fairly high on my list to consider.

The basic idea is to reduce the reference count on 
a variable value that you know is not going to be 
needed again. So in x = sort(x) there would only
be one reference count on the value of x that's passed to sort().
That way, there would be no need to copy x inside sort()
before modifying it. In general, you could look for situations
where a variable is going to be overwritten before it is
read again, therefore its value is no longer needed, and the
reference count could be decremented early, possibly eliminating
a copy.

In addition to being a bit tricky, and a bit dangerous,
this optimization would leave you with some important variables
"undefined" in ex.err and the trace screen, since their 
values might be temporarily unknown. Also, copying a sequence
is a fairly cheap operation compared with any other operation
you can think of that's applied to each element. e.g. one copy
does not increase the cost of sorting by very much
 
> Unless you'd actually implement a var_id() that is orthogonal with
> routine_id()...

It's too much like pointers.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com