Re: Table generation issue

[Steve Heller <steveheller@...>]

Actually, at this point it appears that the main time
was in the table "embedding", so I changed it to
return a table of tables, one subtable for each
dataGenerator object. That about doubled the overall
throughput.

But now I have a different problem, which is that
actually retrieving the data inside my C++ program is
taking a long time, mostly due to "luatolstring". At
this point, I'm thinking maybe I have to return the
data as one long string rather than a lot of small
ones. That might actually be better for my application
because that is the form that the data is eventually
needed in.

By the way, I really appreciate the help from
everyone. Thanks!

--- Asko Kauppi <askok@dnainternet.net> wrote:

> 
> My suggestions, since it's easy for you to measure
> if there's any  
> effect:
> 
> - local data_i= data[i]
> to cache the value, and avoid a number of table
> accesses (locals are  
> fast)
> - local data_i1= data[i][1]
> same thing
> - is 'data[i]' a table of two values that do not
> change?  If so, just  
> use it, not making a copy?
> 
> 
> >     local data = dataGenerator()
> >
> > 	local subTable = {}
> > 	local subTableBlock = {}
> > 	local subTableType
> > 	
> >     for i, element in ipairs(data) do
> local data_i= data[i]
> local data_i1= data_i[1]
> >         if data_i1 == "<type>" then
> > 			subTableType = data_i[2]
> >         elseif data_i1 == "</type>" then
> >         elseif data_i1 == "<block>" then
> >             subTableBlock =
> > {Number=data_i[2],Dup=data_i[3]}
> >         elseif data_i1 == "</block>" then
> > 			subTable[#subTable+1] = subTableBlock
> >         else
> >             if trim(data_i[2]) ~= "" then
> >                 subTableBlock[#subTableBlock+1] =
> data_i	-- in case it only has [1] and [2]
> >             end
> >         end
> >     end
> >
> >     return subTable, subTableType
> >
> > end
> >
> 
> 
> 
> On 21.11.2006, at 17.40, Steve Heller wrote:
> 
> > Unfortunately, my timing runs show that your
> > suggestion makes no measurable difference. Any
> other
> > suggestions would be welcomed.
> >
> > --- Romulo Bahiense <romulo@icontroller.com.br>
> wrote:
> >
> >> I believe the problem is not table allocation,
> but
> >> index access and
> >> length calculation ('#' operator).
> >>
> >> Try this one:
> >>
> >> function
> createFieldDataEntriesForOneDataGenerator(
> >> dataGenerator )
> >>
> >>      local data = dataGenerator()
> >>
> >>      local iSubTable      = 0
> >>      local iSubTableBlock = 0
> >>
> >>      local subTable      = {}
> >>      local subTableBlock = {}
> >>
> >>      local subTableType
> >>
> >>      for i, element in ipairs(data) do
> >>          local a, b, c = element[ 1 ], element[ 2
> ],
> >> element[ 3 ]
> >>          if a == "<type>" then
> >>              subTableType = b
> >>          elseif a == "</type>" then
> >>              -- do nothing
> >>          elseif a == "<block>" then
> >>              subTableBlock = {Number=b,Dup=c}
> >>          elseif a == "</block>" then
> >>              iSubTable = iSubTable + 1
> >>              subTable[iSubTable] = subTableBlock
> >>          else
> >>              if trim(b) ~= "" then
> >>                  iSubTableBlock = iSubTableBlock
> + 1
> >>                  subTableBlock[ iSubTableBlock ]
> =
> >> {a,b}
> >>              end
> >>          end
> >>      end
> >>
> >>      return subTable, subTableType
> >> end
> >>
> >> Note that, in this code, 'data[i]' is the same as
> >> 'element', because
> >> ipairs return key and value.
> >>
> >> --rb
> >>
> >
> 
>