Re: [Eleven-devinfo] Any tips reducing generated code size?

[Joe M. <jd...@po...>]

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