Visual Basic, VB5, Run-time much slower than Design-time

VB5, Run-time much slower than Design-time

Author	Message
KCBow #1 / 10	VB5, Run-time much slower than Design-time I am new to VB5. I have written some very simple test code and noticed that the code executes much more slowly in run-time than in design-time. I have checked the "optimize for speed" box, etc., but I haven't been able to get the run-time execution speed very close to the design time execution speed. Can anyone help me with this? Thanks, Keith
Thu, 16 Nov 2000 03:00:00 GMT

Thorsten Ma #2 / 10	VB5, Run-time much slower than Design-time kcbowen meinte am 31.05.98 zum Thema "VB5, Run-time much slower than Design-time": Quote: > I am new to VB5. I have written some very simple test code and noticed that > the code executes much more slowly in run-time than in design-time. I have > checked the "optimize for speed" box, etc., but I haven't been able to get > the run-time execution speed very close to the design time execution speed. > Can anyone help me with this? What are you doing in yout "very simple test code"? There're some commands, which are 10 times or more slower in run-time then in design- time, for example accessing the product name with App.Productname. -- Jau, tschau. _____ _______________________________________ ^..^ \9 Schweine sind doch auch nur Menschen! WW WW ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fri, 17 Nov 2000 03:00:00 GMT

RJol #3 / 10	VB5, Run-time much slower than Design-time Also, Gosub (why you'd use it, I don't know) is something like 20 times slower in native compiled code -- so if you have a Gosub in a loop... Quote: >kcbowen meinte am 31.05.98 >zum Thema "VB5, Run-time much slower than Design-time": >> I am new to VB5. I have written some very simple test code and noticed that >> the code executes much more slowly in run-time than in design-time. I have >> checked the "optimize for speed" box, etc., but I haven't been able to get >> the run-time execution speed very close to the design time execution speed. >> Can anyone help me with this? >What are you doing in yout "very simple test code"? There're some >commands, which are 10 times or more slower in run-time then in design- >time, for example accessing the product name with App.Productname. >-- >Jau, tschau. > _____ _______________________________________ > ^..^ \9 Schweine sind doch auch nur Menschen! > WW WW ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fri, 17 Nov 2000 03:00:00 GMT

Bill Bec #4 / 10	VB5, Run-time much slower than Design-time I was always under the impression that a gosub was as about as efficient as one could get (a push, run your code, then a pop). I use them extensively rather than calling subs or functions which I assumed took more overhead. What Am I missing here??? Ciao, Bill Quote: > Also, Gosub (why you'd use it, I don't know) is something like 20 times > slower in native compiled code -- so if you have a Gosub in a loop...
Sat, 18 Nov 2000 03:00:00 GMT

Richard Allsebroo #5 / 10	VB5, Run-time much slower than Design-time Try writing reusbale code, why do you think functions and subs were developed?
Sun, 19 Nov 2000 03:00:00 GMT

Bill Bec #6 / 10	VB5, Run-time much slower than Design-time Thanks, now I KNOW what I was missing. Oh well... live and learn. Have to go now, got a lot of recoding to do. Thanks again, Bill Quote: > Apparently this is "by design" in VB5.
Sun, 19 Nov 2000 03:00:00 GMT

Henry S. Takeuc #7 / 10	VB5, Run-time much slower than Design-time Quote: > I was always under the impression that a gosub was as about as efficient as >one >could get (a push, run your code, then a pop). I use them extensively rather >than >calling subs or functions which I assumed took more overhead. > What Am I missing here??? If it's true that VB5 generates C source as intermediate code, then the problem is that C does not have the equivalent of GoSub (because the corresponding Return can occur in any "subroutine"). If so, the GoSub must be simulated with an explicit stack and extra labels, rather than using the CPU's native stack. C doesn't allow you to get the address of a label, so the Return must be implemented as a (potentially) giant switch statement (roughly equiv. to VB's Select Case) containing a bunch of goto's. Why slower? P-code is accessed as data by the interpreter. The result is it's faster because there is no need to use a switch statement (with its indexing or comparison overhead) to implement Return. A simple pop is all that's needed. Henry S. Takeuchi Seattle, Washington (USA)
Tue, 21 Nov 2000 03:00:00 GMT

Henry S. Takeuc #8 / 10	VB5, Run-time much slower than Design-time It has occurred to me that an alternate C-based implementation of GoSub would use setjmp() and longjmp(). An explicit stack is still needed, though, to allow recursion. An unlimited stack would require using malloc() and free() with links--ouch! more overhead. Quote: >> I was always under the impression that a gosub was as about as efficient as >>one >>could get (a push, run your code, then a pop). I use them extensively rather >>than >>calling subs or functions which I assumed took more overhead. >> What Am I missing here??? >If it's true that VB5 generates C source as intermediate code, then the >problem is that C does not have the equivalent of GoSub (because the >corresponding Return can occur in any "subroutine"). > If so, the GoSub must be simulated with an explicit stack and extra >labels, rather than using the CPU's native stack. C doesn't allow you to >get the address of a label, so the Return must be implemented as a >(potentially) giant switch statement (roughly equiv. to VB's Select Case) >containing a bunch of goto's. > Why slower? P-code is accessed as data by the interpreter. The >result is it's faster because there is no need to use a switch statement >(with its indexing or comparison overhead) to implement Return. A simple >pop is all that's needed. >Henry S. Takeuchi >Seattle, Washington (USA) Henry S. Takeuchi Seattle, Washington (USA)
Tue, 21 Nov 2000 03:00:00 GMT

Page 1 of 1

[ 10 post ]