Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Tagz-efficiency (Read 2885 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Tagz-efficiency

Okay, looking through my code, i can find some features which are executed for every file, but probably very rarely are needed. So i'm willing to drop some exotic features to squeeze out a little bit more speed.

But to make reasonable decisions in that regard, i need to know which functions do cause the highest load, and which ones are very fast.

From my own experience, $transition is a real resource hog - which is why i dont use it at all anymore. I can imagine that $blend also is heavy on the cpu.

But there are other functions where i have almost no idea how they relate to speed.

There are mainly 4 functions where it would be very interesting to know where to put them on the speed scale:

$substr, $strstr, $strcmp and $replace.

The first three are selfexplanatory i guess. With $replace i'm curious if it makes much of a difference how many parameters i specify(so, if it makes much of a difference if i specify 10 instead of 2 parameters).

thanks for helping out,
- Lyx
I am arrogant and I can afford it because I deliver.

Tagz-efficiency

Reply #1 –
Test-Scenario: no other resourcehungry apps running (just notepad and fb2k with playback stopped) ui_columns with all global options disabled and no string in it. Only one column with no sorting and color code. Then, the test-code was inserted into this single column and the speedtest executed three times. The results were then averaged.


$strstr - less expensive than expected:
Code: [Select]
$puts(123,123456789)

$strstr($get(123),5)
// above line repeated 50x
// test-result averaged over 3 trials: 388


integer-checking: $if+$strcmp VS. $select
Code: [Select]
$puts(123,1)

$if($strcmp($get(123),1),yes)
// above line repeated 50x
// test-result averaged over 3 trials: 509

Code: [Select]
$puts(123,1)

$select($get(123),yes)
// above line repeated 50x
// test-result averaged over 3 trials: 306

Code: [Select]
$puts(123,5)

$select($get(123),yes,maybe,idunno,possibly,ohyeah)
// above line repeated 50x
// test-result averaged over 3 trials: 416

Conclusion: Checking integers is much more cheap with $select when compared to $strcmp - even more if there are more possible options than 1/0. As a bonus, it looks much more clean and is easier to read.

multiple seperate replace-functions VS. single replace-function with multiple parameters
Code: [Select]
$puts(123,123456789a)

$replace($get(123),1,0)
$replace($get(123),2,0)
$replace($get(123),3,0)
$replace($get(123),4,0)
$replace($get(123),5,0)
$replace($get(123),6,0)
$replace($get(123),7,0)
$replace($get(123),8,0)
$replace($get(123),9,0)
$replace($get(123),a,0)
// above block repeated 5x (totaling 50 replaces)
// test-result averaged over 3 trials: 520

Code: [Select]
$puts(123,123456789a)

$replace($get(123),1,0,2,0,3,0,4,0,5,0,6,0,7,0,8,0,9,0,a,0)
// above line repeated 5x (totaling 50 replaces)
// test-result averaged over 3 trials: 202

Conclusion: Replace is among the most expensive standard-functions - especially when doing many seperate replaces - but doing many replaces in a single replace-function is cheap.

_______________________

Generally, it seems that tagz-efficiency is less a matter of which functions you use, but more a matter of how many seperate functions you use. The number of parameters you specify to a function makes almost no difference.

So, for fast code try to do as manythings as possible with single functions while trying the keep the overall _amount_ of functions(NOT parameters) low.

I didn't test $transition, because as mentioned in the first post, i already had to learn the hard way that its a resource-killer.

- Lyx
I am arrogant and I can afford it because I deliver.

Tagz-efficiency

Reply #2 –
Thanks for sharing the result.

I have been wondering about this, but I've been too lazy to do any testing myself.

Tagz-efficiency

Reply #3 –
Funny coincidence:

As a rule of thumb: the less $'s you have in your code, the more "cheap" it is ;-)

So, musicmusic could just simplify the "speed-test" to counting the amount of dollars in your code
I am arrogant and I can afford it because I deliver.

Tagz-efficiency

Reply #4 –
The "funny coincidence" is that each dollar sign outside of single quotes corresponds to a function call, which is computationally more expensive than - for example - a quoted string of the same length. Additionally, the current parser has an inefficiency with nested expressions, so the average nesting depths is a somewhat important property of a titleformatting script (besides the length and the kind of functions that are used). The nesting depths can be determined as follows:
  • At the start of the script, the nesting depth is zero.
  • For each '(' or '[' that is encountered outside of single quotes, increase the nesting depth by one. For each ')' or ']', decrease it by one.
Of course this only works for a syntactically correct script.

The "Statistics" function of foo_formatedit (link posted elsewhere) can be used to determine the maximum and average (per character) nesting depth.

I'll give an example how the running time of a script can be reduced in general. Consider a script that prints a number of stars based on the play count of a track (simplified):
Code: [Select]
$if(%play_count%,
$ifgreater(%play_count%,10,***,
$ifgreater(%play_count%,5,**,
*)),
not yet played)
It seems quite logical to avoid checking the value of %play_count% more often than necessary by nesting the $if statements. Unfortunately, there is an inefficiency in the current titleformatting interpreter: a character at nesting depth N is read N times. Shoot.

How can this be avoided? Well, take a look at the following:
Code: [Select]
$ifgreater(%play_count%,10,*)
$ifgreater(%play_count%,5,*)
$if(%play_count%,*,not yet played)

Note that this kind of transformation is not guaranteed to improve the performance of a script, but it gave a slight speed-up when I helped picmixer tune one of his. Also do not use the interpreter speedtest of foo_formatedit to tune your script; those figures are not representative of a scripts actual performance as they are determined using a fake track without metadata.

Tagz-efficiency

Reply #5 –
Quote
Unfortunately, there is an inefficiency in the current titleformatting interpreter: a character at nesting depth N is read N times. Shoot.

eek! Does that account for parsing only - or would functions as well be calculated N times?
I am arrogant and I can afford it because I deliver.

Tagz-efficiency

Reply #6 –
Quote
eek! Does that account for parsing only - or would functions as well be calculated N times?[a href="index.php?act=findpost&pid=275403"][{POST_SNAPBACK}][/a]
Only parsing.