Hi Przemek, I've reviewed this old (but highly
critical) code of mine, and could optimize out
FieldPos() calls altogether from the table upgrade
functionality, speed almost doubled and still
working on optimizations. The rest of cases don't
seem to be real a bottleneck.
So it looks like there is no need for HB_FIELDGET/PUT
which accept names in my case.
BTW does __DBTRANS( d, a ) copy one record at
a time?
Brgds,
Viktor
On 2010 Mar 22, at 13:29, Przemysław Czerpak wrote:
> 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
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
