Re: [Eleven-devinfo] Any tips reducing generated code size?
Status: Pre-Alpha
Brought to you by:
jdmorrison
|
From: Joe M. <jd...@po...> - 2005-04-25 03:29:55
|
Hi all,
I'm wading into this thread late, but wanted to respond to this comment:
On Thu, 21 Apr 2005, Madeleine Lemieux wrote:
> I suspect that your approach - assigning the filtered livetable to a local
> table and using a tableformat - is probably more efficient since it only
> triggers one database query to populate the local table. I'm not sure about
> this though.
>
> Can anyone else clarify this issue?
This is generally true - minimizing queries is good for performance, so
it's bad to display a livetable by doing separate queries to select each
row. The best solution is to do what Mike did - before the "display
command, perform a single "filter" command on the livetable, then assign
it to a regular statesafe table to get an in-memory copy. That does a
single SQL query. Then display the table rows using a loop with numeric
index values to access the regular statesafe table.
It doesn't matter if the tables are global or local, since that only
affects where in the program the variable names are visible. For example,
a local table in a subroutine is not visible outside the subroutine
(you'll get an "undefined variable" error if you try to access it outside
the subroutine). But in all other respects apart from visibility, global
and local variables behave identically in Eleven (or at least they are
supposed to!)
One warning: Eleven does not delete local variables when they go out of
scope (that optimization is on the to-do list). So if you copy a lot of
data from a livetable to a regular statesafe table, that statesafe table
is never cleaned up, and all that data will be copied back and forth to
the database, for every program display afterward!
To avoid that performance problem, you can clear the regular statesafe
table after you are finished with it, by artificially filtering the
livetable to return no data, then copying it to the regular statesafe
table. Then you can let the regular statesafe table go out of scope.
Here's the code pattern:
sub foo
{
mylivetable.filter (...);
mytable = mylivetable;
display
{
... display the rows in "mytable" ...
}
// Clear out mytable before it goes out of scope,
// to avoid carrying the data around forever:
mylivetable.filter ("2 > 3"); // select nothing
mytable = mylivetable;
}
In the long run, the last bit will be unnecessary since the Eleven
compiler should clear "mytable" automatically as it goes out of scope.
Best regards,
- Joe
--
Joe Morrison Eleven. One louder.
http://www.powerframe.com http://eleven.sourceforge.net
|