OpenEuphoria

Re: Speed: sprintf vs. & operator

• Posted by jordah at btopenworld.com Jan 07, 2003
• 493 views

Will this solution fix the problem deparse() presented a couple of months
ago.

jordah
----- Original Message -----
From: "Robert Craig" <rds at RapidEuphoria.com>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Speed: sprintf vs. & operator


>
> Rolf Schroeder writes:
> > > t = time()
> > > for i = 1 to 10000000 do
> > >      fullName = fn & " " & mn & " " & ln
> > > end for
> > > ? time() - t
> > >
> >
> > Rob, could you spend a short explanation for this enhancement?
>
> I've optimized expressions that contain multiple concatenations, e.g.
>
>      x = a & b & c & d & ...
>
> In 2.3 (interpreter or translator) it does a straightforward
> left to right evaluation, something like:
>     temp1 = a & b          -- allocate space for temp1, copy a, copy b
>     temp2 = temp1 & c  -- allocate space for temp2, copy temp1, copy c
>     temp3 = temp2 & d  -- etc.
>     etc.
>
> This is the way that operators and operands are normally
> evaluated (in just about any language).
>
> In 2.4, to speed things up, the interpreter and translator do:
>
>    x = a & b & c & d & ...
>
> In *one* step, allocating space for the *final* result x,
> then copying the data for a, b, c, d, ... *once* each.
> So instead of allocating space multiple times,
> it's done once. And instead of copying some of the input data
> multiple times (in effect), each input is copied *once* to the
> final destination.
>
> > Do you have to offer more such impressive improvements for 2.4?
>
> There are some other optimizations in 2.4,
> such as most slices being 30% faster etc.
> It should all be released in a couple of weeks.
>
> Regards,
>    Rob Craig
>    Rapid Deployment Software
>    http://www.RapidEuphoria.com
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>