Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
UDF transmutation
Message
De
12/08/2015 13:18:59
 
 
À
11/08/2015 17:17:43
Mike Yearwood
Toronto, Ontario, Canada
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:
01623206
Vues:
71
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