IniWrite speed limit?

[PepeLapiu]

So my script is pretty much built. Now, I'm just focusing on optimizing it to make it more efficient and speedy.

A lot of it involves IniWrite and IniRead commands. I rely on .INI files a lot. But as I make my script faster, I noticed that some .INI file entries are failing to get written.

So I've put a Sleep, (3*StrLen(INI_entry_file_size)) after every time I use IniWrite. And this seems to have solved the problem. Am I looking at it properly?

I ask because this seems to be counter productive - making the script faster only to end up making it slower.

[mikeyww]

I'm skeptical so far. If you have a script that does not work, I recommend posting it. Indicate what the script does, and what it should do instead.

[PepeLapiu]

I'm skeptical so far. If you have a script that does not work, I recommend posting it. Indicate what the script does, and what it should do instead.

Yeah, I am skeptical too, which is why I am asking here.

What you are asking is difficult to do. It's an 8,000 lines script with 6 different .INI files, and about 5 different functions writing to those .INI files. And it's likely what you guys would call "JUMBO spaghetti code" too.

The IniWrite commands were always very very reliable....until I started to speed up the script and make it more efficient. That is when I started to notice some IniWrite commands were not getting executed. And I noticed that it was almost always during times when a lot of stuff gets written to .INI files. And especially after a long string was written to .INI, the next writing to .INI was not getting executed. Almost as if it's going too fast, and I'm asking it to IniWrite something when the last IniWrite is not finished, so it just skips writing it all together.

So I introduced the following after every IniWrite command:

Code: Select all

tmp:=10*(StrLen(string))
Sleep, %tmp%

And that seemed to have solves the problem for now.
Now I'm just trying to experiment what multiplier is optimum. I just moved from 20* down to 10*. Let's see how well that works.

[ahk7]

The question is why do you need to write it so frequently to ini files, just keep everything in memory and save on exit (or on a timer basis ever X minutes).

[mikeyww]

Good idea from ahk7.

I can think of only six possible explanations.

1. Bug in AutoHotkey.
2. Bug in the script.
3. Faulty storage medium (or corresponding driver, network, etc.).
4. Multiple scripts or programs are writing to the same file at the same time.
5. Virus
6. Antivirus

[PepeLapiu]

The question is why do you need to write it so frequently to ini files, just keep everything in memory and save on exit (or on a timer basis ever X minutes).

Because the code deals with multiple associates and it involves multiple currencies. So account_balance for Bob Smith needs to be distinguished from account_balance for Jane Doe, especially when they can both hold USD and EUR for example.

And I really really don't want to rely heavily on live memory for something as vital as people's currency account balances.

[PepeLapiu]

Good idea from ahk7.

I can think of only six possible explanations.

1. Bug in AutoHotkey.
2. Bug in the script.
3. Faulty storage medium (or corresponding driver, network, etc.).
4. Multiple scripts or programs are writing to the same file at the same time.
5. Virus
6. Antivirus

I'll check those out.

2. Bug in the script.

BLASPHEMY!!! How dare you!?!?

[PepeLapiu]

I should say the script is working on a pretty weak devise (a MS Surface Go 2). But yup, all my problems started when I made the script go faster. And they all went away when I introduced Sleep 10 for every character written into an .INI file.

I'll be testing how much faster I can go before problems start again.

[ahk7]

If the script works then don't fix it

Another option could be: keep everything in memory and write to INI on exit, but instead of writing to INI when you use it - which you observe to be slow - just FileAppend the data to a log file (with timestamps).
This is just an uneducated guess, but I suspect FileAppending a line to a file is faster (I would try to trim the log at the start of the program by FileMove-ing the old log to a backup folder (with an %A_Now%.txt name) so the log files are kept small.

Should the worst thing happen you can either manually retrieve data from the log or write a small script to retrieve and compare the most recent log data and update the INI.

There are functions on the forum to "dump" arrays to XML or JSON data (and read them back into an array) which may be more elegant to use compared to ini - you may wish to look in to that if you want to improve your script. Ini is useful but can be tedious when updating.

[just me]

But yup, all my problems started when I made the script go faster.

So how did you make the script faster?