Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
UDF transmutation
Message
De
10/09/2015 09:32:31
Mike Yearwood
Toronto, Ontario, Canada
 
 
À
12/08/2015 13:18:59
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows Server 2012
Network:
Windows 2008 Server
Database:
MS SQL Server
Application:
Web
Divers
Thread ID:
01623094
Message ID:
01624443
Vues:
98
I just had occasion to change a small udf that did an unconditional OPEN DATABASE to this...

IF DBUSED("DATABASENAME")
IF SET("DATABASE")#""DATABASENAME"
SET DATABASE TO DATABASENAME
ENDIF
ENDIF

and guess what - the app starts visibly faster and things seem snappier overall. Maybe most programmers and most clients don't care about snappy, but I do. dbused is over 600 times faster than open database. I'll gladly take that.

>1000's of times at one time, or 1000's of times distributed over a month/week/day/hour?
>
>The .1ms difference (it's less) of executing 4 lines of prg rather than 1 line of inline code will make no appreciable difference to a form appearing, or a report being ready, if it's called 1 or even 10 times during that process. If it's called 1000's of times in preparing a report, it could make a difference of a second or two, probably. If it's being called 1000's of times in bringing up a form or preparing a single report, I would look at why, and refactor the why.
>
>Additionally: 60% of software development cost in in maintenance, not development. Wrapping common functions to accommodate new options insulates the application in that changes can be made in one place, and apply everywhere. Given the low processing cost for doing so, and the benefits of doing so, I most generally do just that. It has saved our collective rear-facing protuberances on more than one occasion.
>
>Hank
>
>>>>Hey all
>>>>
>>>>I've got a UDF that is something like a cross between SEEK and LOOKUP(). The problem is - calling a UDF is slower than native functions.
>>>>
>>>>The function is liberally scattered everywhere. The parameters do not match the LOOKUP function, which would have been virtually perfect. I know a search and replace might work, but that will break a lot of code too.
>>>>
>>>>So - an idea has been tickling around my mind,
>>>>
>>>>Given the existing call ... MYSEEK(seekthis,"inalias","thistag","returnthis")
>>>>
>>>>would it be possible to #DEFINE and make the above into something native at compile time?
>>>>
>>>>Thanks
>>>Hi Mike,
>>>
>>>the cost of a call to a wrapper function is negligible, unless you are calling it thousands of times, which you shouldn't be doing anyway. So rewrite myseek to use LOOKUP() where appropriate, and you're done.
>>>
>>>Hank
>>
>>We are calling it many thousands of times because of it being used in queries. I disagree with the whole "premature optimization" schtick. Not optimizing at every chance is the true root of all evils.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform