[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: parameter table
- From: Miles Bader <miles@...>
- Date: Sat, 19 Dec 2009 23:09:01 +0900
spir <firstname.lastname@example.org> writes:
>> * much, much, less efficient
> Would you like to expand on this? Do you mean machine time? If yes,
> what should be such costly?
Various reasons: as Linker mentioned, it generates lots of garbage and
so keeps the GC busy; also constructing a table is slower than not doing
so, and accessing elements of a table is slower than accessing arguments.
That's not to say this technique should _never_ be used -- I use it
sometimes, as it can be helpful when the argument list is highly
variable etc. But I don't think it's suitable for "primitive" functions
that are expected to have low overhead, and which might be called a lot;
that also suggests that for consistency reasons, you shouldn't use it
for primitive functions even if they _aren't_ called a lot...
I think it's common to use this technique for "constructors" of somewhat
complex objects, and heavyweight operations that have lots of options.
One compromise I sometimes use is to make a function accept _either_ a
table containing named arguments, or unnamed arguments passed normal;
function foo (x, y z)
if (type (x) == 'table')
y = x.y
z = x.z
x = x.x -- do x last, as it overwrites the table variable
... use x, y, and z ...
That allows the caller to use whichever style is appropriate for his
use, and doesn't have too much overhead when a table isn't used, and
there's only a slight bit of code bloat for the unpacking code.
Education, n. That which discloses to the wise and disguises from the foolish
their lack of understanding.