All Forums >> [Scripting] >> Post a VBScript >> sharing variables between scripts Do you like VisualBasicScript.com? Link to us and help spread the word about our forum. Thanks!
Could you please document your scripts so that those of us who are not familiar with Dynawrap can see what is going on?
_____________________________
"There's the one man who learns by reading, the two men that learn by watching, and the rest of us have to pee on the electric fence for ourselves." - Roy Rogers
"Would you like to touch my monkey?" - Dieter (Mike Meyers)
Yet, more and more I'm making use of temp files and semaphore files. Temp files contain datas to be read while semaphore files are empty but their name is itself a data which can be used as a variable. The advantage of the later is speed: "If file x exists then" is much faster than "open this file and read it all". I noticed that reading a file is also much faster than reading/writing the registry. On my system (which can be very different than yours). As for the example above, IMO, reading on the HD should be faster than doing all these complicated operations. You can't even be sure that this component is not writing on the HD at some point or worse yet, the registry.
I don't know, can't imagine a situation when writing a temporary file is forbiden. If you can use a vbs, it seems that you have enough rights to do what you want. Also if you wrote a vbs files somewhere at the first place, then install ad oc components, you can also write a temp file. If you have been in this situation, I would be happy that you described it to me because that seems to me unlikely.
But for the sake of knowledge, I would be glad if you could comment the code you posted a little bit more. Tell us what this is doing...
As for the example above, IMO, reading on the HD should be faster than doing all these complicated operations. You can't even be sure that this component is not writing on the HD at some point or worse yet, the registry.
"complicated operations" are just reading operations on the hd (once the dynawrap component registred, of course) I'm sure that this component never write on HD because it's an open source component shipped with its program's source and everyone can check it...
quote:
But for the sake of knowledge, I would be glad if you could comment the code you posted a little bit more. Tell us what this is doing...
sorry, I'm a little bit lazy and I'm not a native english speaker but nevermind, soon it'll be done
ORIGINAL: Fredledingue Yet, more and more I'm making use of temp files and semaphore files. Temp files contain datas to be read while semaphore files are empty but their name is itself a data which can be used as a variable. The advantage of the later is speed: "If file x exists then" is much faster than "open this file and read it all". I noticed that reading a file is also much faster than reading/writing the registry. On my system (which can be very different than yours). As for the example above, IMO, reading on the HD should be faster than doing all these complicated operations. You can't even be sure that this component is not writing on the HD at some point or worse yet, the registry. I don't know, can't imagine a situation when writing a temporary file is forbiden. If you can use a vbs, it seems that you have enough rights to do what you want. Also if you wrote a vbs files somewhere at the first place, then install ad oc components, you can also write a temp file. If you have been in this situation, I would be happy that you described it to me because that seems to me unlikely. But for the sake of knowledge, I would be glad if you could comment the code you posted a little bit more. Tell us what this is doing...
Wow. Writing a file is much faster than reading/writing to the registry on your system? Try this code to speedtest.
My results for the above are: File I/O : 3.828125 seconds Registry I/O : 2.6875 seconds
Which shows that the registry access is faster for me. Please post your timings, to help me better understand this. I had thought that the registry access would always be faster, but if it isn't on some systems, then i am going to have to revise some of my codebase.
_____________________________
"There's the one man who learns by reading, the two men that learn by watching, and the rest of us have to pee on the electric fence for ourselves." - Roy Rogers
"Would you like to touch my monkey?" - Dieter (Mike Meyers)
Posts: 123
Score: 2
Joined: 7/13/2006
From: Australia
Status: offline
Hi DiGiTAL.SkReAM,
You must have quick drives, I got on average. File I/O : 8.1 seconds Registry I/O : 2.24 seconds
and with AntiVirus turned off File I/O : 7.5 seconds Registry I/O : 2.21 seconds
I guess a more thorough test for the file I/O would be to record separate times creating the file, writing to the file and reading from the file. Because maybe file I/O is quicker if the file already exists and you don't have to delete it afterwards.
I ran the script on my USB stick and decided to cancel it after about 30 seconds. Doh flash sticks can only be written to a limited number of times. Scratch a couple thousand lives.
I can't run a valid tes now because my computer is busy but from the tests I have done, it seems that you are right: Registry may be faster. I don't know why I have been in a situation when it was not the case.
Interrestingly: This...
For i = 1 To x bFile = oFSO.FileExists("test.dat") Next
would beat this...
For i = 1 To x bReg = oShell.RegRead("HKLM\SYSTEM\Test") Next
by a small margin if the file exists, but would take much loger if it doesn't. I will do more tests to determine what let me think that reading files or reading filenames was faster...
You must have quick drives, I got on average. File I/O : 8.1 seconds Registry I/O : 2.24 seconds
and with AntiVirus turned off File I/O : 7.5 seconds Registry I/O : 2.21 seconds
I guess a more thorough test for the file I/O would be to record separate times creating the file, writing to the file and reading from the file. Because maybe file I/O is quicker if the file already exists and you don't have to delete it afterwards.
I ran the script on my USB stick and decided to cancel it after about 30 seconds. Doh flash sticks can only be written to a limited number of times. Scratch a couple thousand lives.
Hi Meg, Yeah, I blew a big wad of cash about 12 months ago and got top-of-the-line everything. I'd decided that for once, I would know what it was like to have the latest-n-greatest, rather than 3 or 4 generations back as I usually end up with. heh heh
And ya know what? It was everything that I thought it would be, and more.
Well, for this test, we were trying to see if it was quicker to write a value to a 'temp' file or to a temp reg key. That being the case, I thought the sequence was appropriate, sicne the "value" being transferred between scripts could have easily been used as the filename or a part of the filename.
And yeah, feeling yer pain on the whole USB stick thang.
_____________________________
"There's the one man who learns by reading, the two men that learn by watching, and the rest of us have to pee on the electric fence for ourselves." - Roy Rogers
"Would you like to touch my monkey?" - Dieter (Mike Meyers)
ORIGINAL: Fredledingue I can't run a valid tes now because my computer is busy but from the tests I have done, it seems that you are right: Registry may be faster. I don't know why I have been in a situation when it was not the case. Interrestingly: This... For i = 1 To x bFile = oFSO.FileExists("test.dat") Next would beat this... For i = 1 To x bReg = oShell.RegRead("HKLM\SYSTEM\Test") Next by a small margin if the file exists, but would take much loger if it doesn't. I will do more tests to determine what let me think that reading files or reading filenames was faster...
You are correct in that testing for the existance of a particular filename in a loop like that IS faster than reading a key value from the registry, IF the file exists. Otherwise, not. The problem there is that when you are transferring data back and forth between scripts, you will have to do more file i/o than just testing for the existance of a file... you will at least have to modify its filename, if not add/delete data from it. Those are the expensive - in terms of performance - operations. But as for a method of storing data for use in another script - sharing data as it were - that is usefull in as many situations as possible, has the best overall performance, my vote is still with teh registry.
_____________________________
"There's the one man who learns by reading, the two men that learn by watching, and the rest of us have to pee on the electric fence for ourselves." - Roy Rogers
"Would you like to touch my monkey?" - Dieter (Mike Meyers)
I agree.Because I tested the case when the file existed, I'v been wrong. At least with the use of detecting the existance of a certain file for a simple, short piece of datas like a single digit number.
In a slightly different situation, I'm used writing into a temp file to transmit datas to a separate progressbar script (vbs, then hta). Here, instead of erasing the file and write the new number the progress bar has to use, I add to the file content "+1" and the progress bar script execute all the "+1" to get the number. This difference makes things much faster. While calculating all the "+1" takes much more time than reading a number from a file or from the registry,appending "+1" to a textfile is 3 times faster than writing the final number each time into a registry key. In this particular case, it was very important to lose a minimum of time between each incrementation while the script process a large quantty of items in a short time. Now if the purpose is to read the result of the incrementation a lot of time very quickely, this method is to be avoided.
Here is the test to illustrate this case:
I get 0.10 second for file writing and 0.38 second for reg writing.
Now if you need to increment rapidely the number for the progressbar (or anything else) but can't afford the time to execute a string of 20,000 characters (as in this example), you still can append "1" (which is even faster) and calculate the file size to evaluate the numbre for the progressbar. Getting the file size is only 25% slower than reading the number from the registry but you gain is still largely positive ifyou count that the writing phase is 3 to 4 times faster.
All Forums >> [Scripting] >> Post a VBScript >> sharing variables between scripts 
Printable Version
sharing variables between scripts - 
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread