Performance of ReadConfigFile()

[Lagoon]

I'd like to have some hint from experienced scripters about the performance of ReadConfgFile(). In particular, I'm talking about the performance when the config file is already in the core's cache, I don't care about first load performance.
I'm asking because I had the habit to avoid the use of multiple calls of ReadConfigFile() for the same config file in the same script, but to achieve this I had to make my functions more complex, with a npc or item template passed by reference whenever a function deals with npc of general mobiles. Now I'm wondering either this isa good habit or not and I'd like to have your point fo view ^_^

[CWO]

Thats like my habit. I never do the same thing twice in a script. I store it in a variable. If you have a problem with needing to pass it to many functions, make it global in the script declaring it along with your USE and INCLUDE statements.

[Shinigami]

if the config is in the cache and u've not called unloadcfgfile, than it will just search for the name+ref in an array and return it. if u've used unloadcfgfile, but the files wasn't changed on disc, core will do as same as like described before + core will check the file-properties on disc to make sure, it's not modified. if it was modified, than core will reload it...

so, it's very fast, because core does near nothing

Shinigami

[Marilla]

You know how I like to make long posts! Well, here's one;

I wanted to test exactly how true this was. I know it's true, because my scripts make numerous, repeated calls into config files in some fairly high-priority systems - such as my combat hook.

So, I put together the following test:

Code: Select all

use uo;
use cfgfile;
use polsys;

program testcfgfile(who)
	var dummy, i;
	var REPEATS := 100000;
	SendSysMessage(who, "Target an item that has an itemdesc entry");
	var what := target(who);
	if (!what) return; endif
	var ending;
	var start := ReadMillisecondClock();
	SendSysMessage(who, "checking/setting property "+cstr(REPEATS)+" times");
	for (i:=1;i<=100000;i:=i+1)
		dummy := what.desc;
	endfor
	ending := ReadMillisecondClock();
	SendSysMessage(who, "Done. Took: " + cstr(ending-start) + " ms");

	var itemdesc := ReadConfigFile(":*:itemdesc");
	var elem;
	start := ReadMillisecondClock();
	SendSysMessage(who, "loading/checking itemdesc "+cstr(REPEATS)+" times");
	for (i:=1;i<=100000;i:=i+1)
		elem := FindConfigElem( itemdesc, what.objtype );
		dummy := GetConfigString( elem, "desc" );
	endfor
	ending := ReadMillisecondClock();
	SendSysMessage(who, "Done. Took: " + cstr(ending-start) + " ms");
	
endprogram

As you can see, it iterates through first reading a simple prop on the item 100,000 times and saving that into a variable, and then doing the same thing by finding the config file element and reading the value into the variable.

The results on my test system were: 1110ms for the simple reading of the property, and 1460 for reading the elements and getting the property from there.

Percentage-wise, that's a significant difference. However, of course, that's having to locate and load a config file entry 100,000 times, and then reading a value from it... as opposed to simply reading the value straight from an object instance. When you consider that you would never actually make code that loops this 100,000 times, the difference in more real-world scenerios becomes basically nil.

I would definitely agree that if you already have a value that you are going to use multiple times, certainly you want to store the value in a variable and reuse it. However, I think this shows that there's no reason at all to be shy about using config files when they are the most elegant solution... as is the case particularly when we're talking about config files that are already going to be loaded into memory anyway - itemdesc and npcdesc.

[Lagoon]

Thank you all, you gave me interesting points of view to better evaluate the problem ^_^