1. Speed: sprintf vs. & operator
- Posted by jc at cowgar.com
Jan 07, 2003
What's quicker?
same in both:
fn = "John"
mn = "David"
ln = "Doe"
first example:
fullName = fn & " " & mn & " " & ln
or:
fullName = sprintf("%s %s %s", {fn,mn,ln})
?
Thanks,
Jeremy
2. Re: Speed: sprintf vs. & operator
> What's quicker?
> fullName = fn & " " & mn & " " & ln
> or:
> fullName = sprintf("%s %s %s", {fn,mn,ln})
According to my test, the first one is faster...
--- Test Procedure
include get.e
object junk
atom time1, time2
atom iters
sequence fn, mn, ln, fullName
iters = 1000000
fn = "John"
mn = "David"
ln = "Doe"
time1 = time()
for t=1 to iters do
fullName = fn & " " & mn & " " & ln
end for
time1 = time() - time1
time2 = time()
for t=1 to iters do
fullName = sprintf("%s %s %s", {fn,mn,ln})
end for
time2 = time() - time1
printf(1,"For %d iterations:\ntime1 = %d\ntime2 = %d\n",
{iters,time1,time2})
junk = wait_key()
--- End Test Procedure
3. Re: Speed: sprintf vs. & operator
jc at cowgar.com wrote:
> What's quicker?
> fullName = fn & " " & mn & " " & ln
> or:
> fullName = sprintf("%s %s %s", {fn,mn,ln})
> ?
After a few tests I'm convinced the former is around 4 times faster than the
latter. Go with the ampersands :)
Hint:
constant SP = ' '
--
-- other code
--
fullName = fn & SP & mn & SP & ln
...is faster still.
Carl
--
[ Carl R White -=- aka -=- Cyrek the Illogical ]
[ () E-mail...: cyrek{}cyreksoft.yorks.com ]
[ /\ URL......: http://www.cyreksoft.yorks.com ]
4. Re: Speed: sprintf vs. & operator
In Euphoria 2.4 alpha, the following runs 2.6x faster
than it does in 2.3...
sequence fullName, fn, mn, ln
fn = "George"
mn = "Walker"
ln = "Bush"
atom t
t = time()
for i = 1 to 10000000 do
fullName = fn & " " & mn & " " & ln
end for
? time() - t
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: Speed: sprintf vs. & operator
- Posted by r.schr at t-online.de
Jan 07, 2003
Robert Craig wrote:
>
> In Euphoria 2.4 alpha, the following runs 2.6x faster
> than it does in 2.3...
>
> sequence fullName, fn, mn, ln
>
> fn = "George"
> mn = "Walker"
> ln = "Bush"
>
> atom t
> 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? Do you
have to offer more such impressive improvements for 2.4?
Have a nice day, Rolf
6. Re: Speed: sprintf vs. & operator
On Tue, 7 Jan 2003 12:00:26 -0500, Robert Craig
<rds at RapidEuphoria.com> wrote:
>In Euphoria 2.4 alpha, the following runs 2.6x faster=20
>than it does in 2.3...
>
> fullName =3D fn & " " & mn & " " & ln
Is that 2.3 running on your old PC? 
Nice one Rob! How on earth did you manage that?
jc, if you really need it, you can get an additional 20% improvement
in 2.3 with:
fullName =3D fn & SP
fullName &=3D mn
fullName &=3D SP
fullName &=3D ln
As this takes better advantage of some optimisations in the 2.3
interpreter. I expect both forms will be the same speed in 2.4
Pete
7. 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
8. Re: Speed: sprintf vs. & operator
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!
>
9. Re: Speed: sprintf vs. & operator
On Tue, 7 Jan 2003 14:40:53 -0500, Robert Craig
<rds at RapidEuphoria.com> wrote:
>In 2.4, to speed things up, the interpreter and translator do:
> =20
> x =3D 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.
That is so blindingly obvious it is terrifying.
Like everyone else, I may well have 20:20 hindsight sometimes,
but that thar above ain't nothing but dainty
Pete
10. Re: Speed: sprintf vs. & operator
Jordah Ferguson writes:
> Will this solution fix the problem deparse()
> presented a couple of months ago.
It will only be faster when you have multiple concatenations
in one expression. The version of deparse() that I looked at
just now, has only single concatenations at a time.
If you change the code to do multiple concatenations
(when there are 3 or more items to concatenate)
then it will be faster in 2.4.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
11. Re: Speed: sprintf vs. & operator
Hi Rob,
Not sure what version of deparse u are mentioning but here is the
original test code i presented to you. will deparse_old() be as fast as
deparse_new()
Jordah
--original derparse()
global function deparse_old(sequence list, integer c)
sequence s
if length(list) then
s = list[1]
for i = 2 to len by 1 do
s =s&c&list[i]
end for
return s
end if
return ""
end function
global function deparse_new(sequence list, integer c)
sequence s
if length(list) then
s = list[1]
for i = 2 to length(list) by 1 do
s =s&c
s=s&list[i]
end for
return s
end if
return ""
end function
----- Original Message -----
From: "Robert Craig" <rds at RapidEuphoria.com>
To: "EUforum" <EUforum at topica.com>
Sent: Wednesday, January 08, 2003 12:51 AM
Subject: Re: Speed: sprintf vs. & operator
>
> Jordah Ferguson writes:
> > Will this solution fix the problem deparse()
> > presented a couple of months ago.
>
> It will only be faster when you have multiple concatenations
> in one expression. The version of deparse() that I looked at
> just now, has only single concatenations at a time.
> If you change the code to do multiple concatenations
> (when there are 3 or more items to concatenate)
> then it will be faster in 2.4.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
12. Re: Speed: sprintf vs. & operator
Jordah Ferguson writes:
> s =s&c&list[i]
>
> versus...
>
> s =s&c
> s=s&list[i]
I didn't time it, but I think the first one will be
slightly faster in 2.4 than the second.
Only slightly, because c is an atom (integer)
in this case, and s = s & c should be fairly fast.
If you are obsessed with speed,
you could have a different statement for every
number of items (up to some limit), e.g.
if length(list) = 1 then ...
s = ...
elsif length(list) = 2 then ...
s = ...
elsif length(list) = 3 then
s = list[1] & c & list[2] & c & list[3] -- for example
elsif length(list) = 4 then
s = ...
elsif ...
else
-- handle larger numbers with a loop,
-- doing 5 at a time or something
end if
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
