General consensus of execution time between a wbt vs a compiled WBT as an EXE

[mhamlett101]

General consensus of execution time between a wbt vs a compiled WBT as an EXE
trying to get a general feel for the execution time of an interpreted WBT program vs the same program running as an EXE.
what are people's thoughts?
is it just a slight difference?
is this too vague to time the difference because it may depend on the statements used such as reading 1000 lines of a text and then executing 1000 INSERT SQL statements?
my thoughts would be that a high database usage program that loops thru 1000's of lines of code may execute quicker if complied. 

im going down a road right now with loading a database with dozens of incoming text files to dozens of tables and Im wanting others experience on whether they run interpreted or always run compiled.
thanks

[JTaylor]

Can't really speak to time difference AND you probably already know this but...

It will make a HUGE difference if you batch up your statements.   Don't do too many as the manipulation of large strings in WinBatch is VERY slow.  Depending on the data 500 usually works fairly well.   If you are reading through a file and formulating the SQL rather than just a file import (which makes much of what I am saying moot) you may find the MOD operator useful.    Also, most databases allow you to have one insert statement and many rows of data to be inserted.  This will also make a HUGE difference.

Again, probably old news but I do a lot of data and database related stuff and these are some things that I have found to be useful.


Jim

[stanl]

Agree with Jim. I would think initially running interpreted would make i easier to debug and possibly set internal timers. Would need more information as to whether your text files would comply with ADO or ADO.Net operations for single insert of multiple rows. Also, depending on the specific database there may be specific command or functions to speed up data processes.

[ChuckC]

Hmm... I doubt that the speed of execution of SQL statements is significantly affected by whether the script is run from a .WBT file or pre-compiled into a .EXE.

Remember, a script compiled to a .EXE is nothing more than a stub .EXE file with a .WBC file embedded inside it and some minimal native code required to load the WIL interpreter and instruct it to start processing the tokenized [pre-compiled] WBC content.

If you were to execute a script a .WBT file 100,000 times in a row, you'd incur the overhead cost of tokenizing that script once per loop iteration.  If you ran a .EXE containing a compiled script, you wouldn't pay the tokenizing cost at all.

IIRC, WinBatch and PoweShell both completely tokenize every script at the time that the interpreter loads the script into memory, as this is necessary before the interpreter can actually execute the script code.

[JTaylor]

Another thing, if you are not aware....and this seems to be an ODBC thing, not a WinBatch thing.   If you batch statements, it seems to only return success information for the last statement.   This means, if the first 499 inserts fail but the last one succeeds it won't return an error.   Not sure this is the case for all Drivers but I have encountered this issue more than once.

Jim

[kdmoyers]

My $0.02

I agree with above comments:

compiled vs interpreted winbatch -- no detectable difference in speed.

individual vs batched SQL calls -- HUGE difference in speed.

-Kirby

[td]

A compiled WinBatch script *may* execute a little more quickly under certain conditions but, as mentioned, the differences are minimal. There used to be a significant performance difference between 32-bit and 64-bit execution of script but the later generations of processors have eliminated most of the 32-bit disadvantage.   

String processing using WinBatch may or may not be slow. It all depends on what you are trying to do and how you do it.

Also as mentioned, database processing is best performed in bulk by the database engine.