Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

IniWrite, IniDelete


  • Please log in to reply
6 replies to this topic
Azevedo
  • Members
  • 179 posts
  • Last active: Nov 04 2015 04:37 PM
  • Joined: 07 Mar 2012

I noticed every time I call IniWrite it access the file on disk, write to it and then close the file object/handler.

Imagine writing 50 entries how uggly it is. It is not right.

Why not write all entries at once?

 

I sugest adding an extra parameter to IniWrite and IniDelete called COMMIT

IniWrite, Filename, Section [, Key], COMMIT := False

so the phisical file is only actually written when COMMIT is true

 

Or...

IniAdd, Filename, Section [, Key]
IniAdd, Filename, Section [, Key]
IniAdd, Filename, Section [, Key]
IniWrite()


Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
Is the performance actually a problem or are you just imagining it because you "noticed" that it accesses the file every time?

The OS has a cache for file system access. It does not necessarily access the physical disk immediately or every time you write to or read from a file.

See also speed up IniWrite.

In recent versions, you can also speed things up by reading/writing whole sections at a time.

Azevedo
  • Members
  • 179 posts
  • Last active: Nov 04 2015 04:37 PM
  • Joined: 07 Mar 2012

Of course it is not noticed by the user.

But I just don't feel comfortable knowing that there are I/O being made multiple times uncecessarily.

I may write a ahk class to manage ini myself.

But thanks mate!



Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

But I just don't feel comfortable knowing that there are I/O being made multiple times uncecessarily.

Why? If the file is in disk cache, the "I/O" is just reading/writing memory.

I may write a ahk class to manage ini myself.

You could draw inspiration from one of the existing scripts.

The thing about custom INI routines is that they never have exactly the same behaviour as Windows, or every other application which uses the standard routines. Also, depending on how you use it, your script might fail to write the changes back to file, such as if the script terminates unexpectedly.

Azevedo
  • Members
  • 179 posts
  • Last active: Nov 04 2015 04:37 PM
  • Joined: 07 Mar 2012

This code illustrates what I meant:

IniWrite, test value1, c:\test.ini, Settings, TestKey1
MsgBox, Check you ini file and click ok.
IniWrite, test value2, c:\test.ini, Settings, TestKey2
MsgBox, Check you ini file and click ok.
IniWrite, test value3, c:\test.ini, Settings, TestKey3
MsgBox, Check you ini file and click ok.

I may be wrong but I don't agree with writing line by line. Or reading line by line...

In my mind the right way to do that is read/write the whole file contents to the memory and only write to the disk ONCE.

 

Now, this is neat:

FileRead, FileContents, C:\My Documents\My File.txt
MyFile := StrSplit(FileContents, `r`n)
Loop % MyFile.length() {

}

And this is awfully uggly:

Loop
{
    FileReadLine, line, C:\My Documents\ContactList.txt, %A_Index%
    if ErrorLevel
        break
    MsgBox, 4, , Line #%A_Index% is "%line%".  Continue?
    IfMsgBox, No
        return
}

Just because we have super fast machines today then it means we can write a wasteful code since the OS will handle it?



T_Lube
  • Members
  • 640 posts
  • Last active: Sep 09 2016 02:19 AM
  • Joined: 16 Oct 2014

I would recommend looking at the various ini object classes that are around and maybe modifying it the write whole sections or files using for-loop on the object if needed. I have done something like this using an old version of AHK_L (don't judge it's what I have at work and my admin won't take the time to update) to do something like this.



Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

This code illustrates what I meant:

I think that's a poor demonstration. I would very much expect the effect of the IniWrite command to be immediate - when the user checks their INI file as instructed by the MsgBox :p, they should find the setting which was just written. What if the script uses some command other than MsgBox, which relies on the setting having been written? For instance, RunWait (running a program after having modified its configuration).
 

Just because we have super fast machines today then it means we can write a wasteful code since the OS will handle it?

Yes. I'd much rather waste CPU cycles than my own time.

That's not the point, though. The "waste" of the INI commands is inconsequential.

The INI functions were designed for 16-bit Windows, back when computers were much less powerful. If your INI files get large enough to cause efficiency problems, you've probably gone way past what INI files were designed for.


As for your other examples, I believe a file-reading loop would be better.