On Mon, 22 Mar 2010, Szak�ts Viktor wrote:
Hi,
> - Transferring records from one table to another,
> with overlapping set of fields but different structure.
> (to/from temp tables f.e. for quick browsing or editing
> sub-tables)
> - Upgrading tables to new structure.
> And this pretty much sums up all the places where
> FIELDGET(FIELDPOS()) dual-calls are made. All of above
> is speed critical, especially the second. As far as I
> checked quickly the second is safe, the first not
> necessarily.
I do not agree with your conclusion.
If it's speed critical in your code then you should eliminate
any field accessing by name which is the most expensive part
of field access/assign operations and use only field indexes.
I.e. at atartup you can create array with indexes which should
be translated between areas:
select( nSrc )
aTrans := {}
for i := 1 to fcount()
cField := fieldName( i )
if ( j := ( nDst )->( fieldPos( cField ) ) ) != 0
aadd( aTrans, { i, j } )
endif
next
dbGotTop()
select( nDst )
while ! ( nSrc )->( eof() )
dbAppend()
for each aField in aTrans
fieldPut( aField[ 2 ], ( nSrc )->fieldGet( aField[ 1 ] ) )
next
( nSrc )->( dbSkip() )
enddo
For tables which have very big number of fields the speed
improvement should be huge. Accessing fields by name is
relatively very slow operation and all RDD methods which
transfer records between workareas use such translation
table with indexes to eliminate it.
And you can use RDD directly for such operation, i.e.:
select( nSrc )
aTrans := {}
for i := 1 to fcount()
cField := fieldName( i )
if ( nDst )->( fieldPos( cField ) ) != 0
aadd( aTrans, cField )
endif
next
__dbTrans( nDst, aTrans )
Functionally it makes exactly the same job as the first code
but in C code eliminating and .prg code overhead. Additionally
some remote RDDs can move the whole operation to the server
side. The second code should work also with Clipper.
> [ Anyway regardless of my actual (or general) usage
> patterns, it's IMO bothersome to introduce RTE here,
> since it bends the original functions in the same domain
> in unexpected way. Or maybe we should form a general
> concept as to when to throw RTEs and when not, in
> extended (HB_*) core functions. ]
I do not think that we can generalize generating RTE depending
on HB_ prefix in function name.
best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
