lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Thu, 25 Mar 2004, Taj Khattra wrote:

> > Well, I tried a simple test, but lua complained -- I think the arguments
> > to collectgarbage need to be ints rather than strings!
> are you sure you're using 5.1-work - it seems like you may
> be using 5.0 instead ?
> ...
> you could use print(_VERSION) to confirm the version:

Thanks for the tip -- it was late last night! I rebuilt today, the version
checked, now works as expected.

Same behavior, though.

> > Anyway, I found it started quite spritely but, now at n = 296000 it's very
> > slow (99.1% cpu according to top).
> i think that is expected because the loops are moving a lot of data
> and creating lots of garbage as n gets bigger.
> section 11.6 of Roberto's book explains why in more detail.
> it has also been discussed on this mailing list in the past:

Sure, I know that, thanks for looking up the reference anyway. I'm
deliberately though trying to generate loads of garbage to be collected.
(Otherwise I'd use table.concat (or LTN #9).

Just for fun, I tried the same script on python (v. 2.3.3), which uses
reference counting and whose strings are immutable. Got similar results,
except (again, untimed, just looking at the console) response degrades it
better than lua's (as far as n=493000).

Finally, tried perl (v. 5.8.0), which also uses reference counting but
whose strings are NOT immutable.

When I concatenated string $a via
	$a = $a . "X";

results were basically in line with lua & python (though faster); however
when I used
	$a .= "X";

(which appends to the string 'in-place', if you're not familiar w/ perl,
by analogy to c, likes like using 'n += 1' instead of 'n = n + 1')

then it completed the script in 2 seconds (!).

Now to design another test -- maybe generate thousands of closures which
reuse the same names.