Does the use of the "alias-assignment" '->' operation interfere with the performance of the application?

Question

In the descending languages of Clipper, there is an operator called "the alias. For example, I can take a field of one result set from that operator (example in ADVPL):

cSQL += " SELECT "
cSQL += "  TOP 1 1 EXISTE "
cSQL += " FROM ( "
cSQL += cQuery
cSQL += " ) AS X "
cSql := changeQuery(cSQL)
DBUseArea(.T.,'TOPCONN',TCGENQRY(,,cSql),_cAlias,.F.,.T.)

// uso do alias-assignment
nRet := (_cAlias)->EXISTE
// uso do alias-assignment para um método
(_cAlias)->(dbCloseArea())

But I have no idea what’s going on under the table. My application has a lot of use of this, so if there is some kind of execution being performed on Runtime by language, this processing will take time that would otherwise be dedicated to making computations in my application.

Another example, in which maybe there is some abuse of the operator:

dbSelectArea("ZX1")
ZX1->(dbSetOrder(1))
ZX1->(dbGoTop())
ZX1->(dbSeek(cChave))

While !(ZX1->(EOF())) .AND. cChave == ZX1->(ZX1_FILIAL + ZX1_COD)
    aadd(aZX1Stuff, { ZX1->ZX1_TIPO, alltrim(ZX1->ZX1_CP_PRO), alltrim(ZX1->ZX1_CP_GEO), ZX1->ZX1_TAM })
    ZX1->(dbSkip())
EndDo
ZX1->(dbCloseArea())

So my doubts are:

• use/abuse the -> in Clipper or derivatives (such as Harbour or ADVPL) generates some measurable impact on application performance?
• if yes, how can I measure that time?
• if yes and if I measure as a valid point of optimization, how could I do to optimize its use?

Answer 1

Only one correction: in the descending languages of dBase II :) xbase calls. Clipper is already descending.

Originally dBase II had a very simplified language with syntax that reminded a little COBOL but applied more directly to something that was a little new at the time, the one of the relational database. Access to database members was done by simple imperative commands.

On the PC came dBase III with some things that started to move slightly away from this because the language started to have more programming resources and started to have a syntax that reminded a little Pascal or C, but it was just something very punctual and new.

For performance and ease of distribution someone decided to create a dBase compiler, the one of the Clipper. With time some Features were being added to get more expensive programming language, being able to extend some things. There they invented this notation that looked like an access to a compound object, as was the struct from C, then you put the name of the object, the operator (if we can call it that) that some say is contextualized and the member that could be a field from the database table or a function that acts on it. It only works in tables and this context is always in which table the operation will be made.

The coolest part is that people could stop naming prefixed fields using the table name. At first I needed it because you were left with no visual context, which obviously complicated readability. Allowing, but not obliging, the name of the table is no longer necessary to give names with hungarian notation in the fields. What was a relief because the fields could only have 10 characters in the name.

The Clipper 5 changed everything, they decided to break with the dBase that was really sinking and turned into a programming language that by chance accessed a database. This notation strengthened and in fact, although the previous syntax worked through the language’s excellent preprocessor, Clipper 5 actually looked more like C (a touch of BASIC) than COBOL, and the use of prefixes became the standard.

Of course, Totvs did not understand this and did not have a default to use the prefix or not even in its newer version of ERP which was 100% written in Clipper 5. So they still use Hungarian notation. I suggested to fix this before it became impractical to change, which gives to imagine how important the gain would be and have 4 extra characters to better express in the field names. Did not accept.

When the ADVPL appeared they continued the same way, and in fact it would be difficult to change at that time (I would still try to change at least the novelties, which doesn’t look beautiful, but helps).

I can’t tell if the Clipper Summer 87 had a performance difference between using one shape or another, but it was probably the same as the Clipper 5 that had a very small difference, one that you can barely measure even in large volumes. I have never measured in Harbour and ADVPL less yet, but it is highly likely, and by history may even have some additional cost, but still irrelevant, you should not worry about it. IF ADVPL get too slow it won’t surprise me, but I doubt it will be very serious (good had a bug in Clipper Summer 87 SKIP -1) was tens or hundreds of times slower than the SKIP 1, and the tree allowed to make both at the same time. A lot of people bought Joiner’s pump just because of this :)

I don’t know ADVPL measurement methods except taking the Time() :)

I doubt there’s a way to optimize it, and it’s worth it. Anyway it’s almost certain that it will be premature optimization, you’re not needing it for your code to become faster. " I guarantee" that if someone moves a little bit in those internal functions they can give a bigger gain, and nobody wants to do this.

For reasons of readability you should forget that there is such a dbSelectArea() or SELECT.

Of course, it works better when you don’t use Hungarian notation. As they use I don’t even know if I should use the prefix (some cases have no way not to use or complicates the code too much), it would be more readable because there is no redundancy. But I still prefer its use as standard.

I can not talk about the implementation of ADVPL but in Harbour the function analyzes the context that it is and makes exchange for internal access, so simply is falling into a if that changes a value. The fact that this possibility exists has already slowed everything down, even if you are not using this prefix, but again irrelevantly. The compiler controls the context state globally, it is even made.

Reinforcement that in a language basically of script that runs on a VM (which for ADVPL is not optimized) it does not even tickle, you lose absurdly more for other reasons.

I think "abusive" use the two selection mechanisms of the table, should choose one or the other.

Try this:

ZX1->(dbSetOrder(1), dbGoTop(), dbSeek(cChave))

I put in the Github for future reference.

This improvement is only for the sake of readability, not having so much redundancy, will not improve performance. Anyway this dbGotTop() shouldn’t make any sense, but it might be because of some problem of implementing the access system to SQL tables. I don’t know if you noticed you use the methods of accessing old Clipper DBF tables in a kind of cursor generated by query in the database through SQL.

My DbSeek() and other functions had a parameter with index order. I put it out for everyone to use, practically nobody used, I think they believed that writing more lines gave the impression of being more productive.

Until recently I could still use only 10 characters in ADVPL. Some things now (right now) can use more characters, but I don’t know if field names. At least in table fields custom I wouldn’t use Hungarian notation, even to help differentiate.

Answer 2

Let’s see:

use/abuse -> in Clipper or derivatives (such as Harbour or ADVPL) generates some measurable impact on application performance?

Answer:

There is time difference, but we are talking about nanoseconds of difference. This difference will only represent something close to a second difference in a processing that you make more than a million and a half alias exchange.

if yes, how can I measure that time?

Answer:

Since the time is very short, you need to make a LOOP with many iterations, using an aliased expression with no processing cost. For example, check for EOF() or ask for the RECNO() table. You can take the time in seconds, with precision of thousandths of a second using the function seconds() and storing their return in a variable before starting to process, making one or two million iterations using the aliased expression, measure the time by subtracting the return of the function seconds() after processing the variable that saved the seconds() before processing. Then repeat the same loop with timekeeping, but calling EOF() and RECNO() unused (cAlias)->(xxx)

In a local test, a loop of 10 million iterations with aliased expression made 1.5 million iterations per second. Without the aliased expression, and without changing the alias, it rose to 2.3 million iterations per second. However, if inside the loop I put -- instead of the expression (cAlias)->(Eof()), i make a DbSelectArea(cAlias) and then check by EOF(), performance drops to 1.2 million iterations per second. This means that the difference between using or not aliased expression is only 2.31e-7 seconds , or 0.000000231 s.

if yes and if I measure as a valid point of optimization, how could I do to optimize its use?

Answer:

The Maniero tip is cool, if you have more than one operation to do in the same alias, condemn within the aliased expression. However, this can harm the readability of the code -- and because of some nanoseconds of difference. -- I personally don’t think it’s worth it. If in your entire process, which takes a few minutes, you switched aliases two million times, and it took a second, optimizing it to 0.7 seconds is nothing in total time.