OpenEuphoria

RE: 2.4 problems

• Posted by Andy Serpa <ac at onehorseshy.com> Jun 09, 2003
• 397 views

Andy Serpa wrote:
> 
> 
> Andy Serpa wrote:
> > 
> > 
> > > I hope you can narrow it down.
> 
> I have narrowed it down!  I don't have a simple example yet (in code)

Now I do.  The following rather strange program seems to do the trick:

---------------------------------------------------------------------
include machine.e

function seq_transform(sequence s)
sequence snew
	snew = {}
	for i = 1 to length(s) do
		if rand(2) = 1 then
			snew &= int_to_bytes(s[i])
		else
			snew &= atom_to_float64(s[i])
		end if
	end for
	return snew
end function


object t, x, s1, s2, s3, s4

s1 = {}
s2 = {}
s3 = {}
s4 = {}

puts(1,"Creating big sequences...\n")
for i = 1 to 500000 do
	s1 &= rand(1073741823) * 100
	s2 &= rand(1073741823) * 100
	s3 &= rand(1073741823) * 100
	s4 &= rand(1073741823) * 100
end for

puts(1,"Processing sequences...\n")
t = time()
for i = 1 to 50 do
	x = seq_transform(s1[rand(10000)..20000])
end for
? time() - t
--s1 = {}


t = time()
for i = 1 to 50 do
	-- uncomment the following line to see just how slow
	-- ? i
	x = seq_transform(s2[rand(10000)..20000])
end for
? time() - t
--s2 = {}

t = time()
for i = 1 to 50 do
	x = seq_transform(s3[rand(10000)..20000])
end for
? time() - t
--s3 = {}

t = time()
for i = 1 to 50 do
	x = seq_transform(s4[rand(10000)..20000])
end for
? time() - t
--s4 = {}


puts(1,"\n\nDone.")
t = gets(0)


---------------------------------------------------------------------


The above is the fast version.  Timings are about 1.4 seconds per 
sequence on my system.  Now comment out the "s1 = {}" etc lines and it 
grinds to a near halt when processing the second sequence. (Uncomment 
the "? i" to see it get slower & slower.)

Other things to notice:

-- The "seq_transform" function seems to be important. (This is taking 
the place of compress() for purposes of this example.)  If you alter 
this function so it uses "int_to_bytes" only or "atom_to_float64" only 
instead of mixing & matching the two, the slow-down does not occur.

-- The slow-down also does not occur if you keep the integers in the 
31-bit range.  Take out the " * 100 "'s and that becomes evident.