Mike Yearwood
Toronto, Ontario, Canada
Information générale
Catégorie:
Codage, syntaxe et commandes
Versions des environnements
Network:
Windows 2008 Server
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
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement