# 19,825 lines of code



## dfhagai (Nov 28, 2018)

Hi,

I've wrote a script in Sublime, using a lot of custom function.
Before compile, the code was 3268 lines long.
After compile, the code turned into 19,825 lines of code.
It's probably the functions that caused this extra length

My question is - does it sound like a legitimate size for a script?
Whats worries me is latency issues due to the script length...
Is there a simple way to measure it?

Many Thanks,
HD


----------



## d.healey (Nov 28, 2018)

You won't get latency but that's a crazy script. Try using task functions instead of regular functions this should reduce the size of the code considerably.


----------



## INCIRIOS (Nov 28, 2018)

Really depends what you're doing, but it sounds like there's a lot of optimisation to be done. 2000 lines of code is normally plenty, including UI. If you're adding FX and extra tabs/mixers etc then maybe more, but almost 20k seems quite a lot.


----------



## dfhagai (Nov 28, 2018)

d.healey said:


> You won't get latency but that's a crazy script. Try using task functions instead of regular functions this should reduce the size of the code considerably.


Thanks David! I've learned all about functions from your videos 
where can I find info about task functions?


----------



## INCIRIOS (Nov 28, 2018)

dfhagai said:


> Thanks David! I've learned all about functions from your videos
> where can I find info about task functions?


https://nilsliberg.se/ksp/scripts/tutorial/editor.html#function_taskfunc


----------



## dfhagai (Nov 28, 2018)

Light and Sound said:


> https://nilsliberg.se/ksp/scripts/tutorial/editor.html#function_taskfunc


Will look into it. Thank you!


----------



## EvilDragon (Nov 28, 2018)

Task functions are not really necessary unless you're doing possibly reentrant functions (functions that have wait() in them).

I can see this as legitimate if you have a lot of UI controls that do a similar thing (i.e. - a mixer for all 16 instrument busses, with some FX loaded that all of them use always) and you used macros instead of (or in conjunction with) callable functions to cover their UI callbacks.



d.healey said:


> but that's a crazy script.



No, 19k lines is far from crazy.  Just depends what is being done.

You know what's crazy? 8dio marketing their FX rack having a *whopping over 100k *lines of code! That's crazy. Because it just means it's not coded efficiently at all. I bet the same script with exactly the same functionality can be done in wheraeabouts of one tenth of that line count.


----------



## dfhagai (Nov 28, 2018)

EvilDragon said:


> I can see this as legitimate if you have a lot of UI controls that do a similar thing (i.e. - a mixer for all 16 instrument busses, with some FX
> 
> No, 19k lines is far from crazy.  Just depends what is being done.
> 
> You know what's crazy? 8dio marketing their FX rack having a *whopping over 100k *lines of code! That's crazy. Because it just means it's not coded efficiently at all. I bet the same script with exactly the same functionality can be done in wheraeabouts of one tenth of that line count.



I feel much better now, thank you


----------



## Mike Greene (Nov 28, 2018)

Fewer lines is a good goal in general, but sometimes I'll skip line-saving efficiencies just because there are times when the "longer way" is more readable. For me, at least. For instance, I like to be able to see at a glance, _"Oh, here's where I declared the swing slider and here's its range,"_ rather than tracking to arrays where the settings are.

Also, in certain instances, fewer lines doesn't necessarily mean the script is more efficient. Since my scripts often have pattern players, there are certain instances where there's a ton of stuff going on exactly on a downbeat, so those microseconds can start adding up to milliseconds. I need to trim as much time as possible, so I have to think in terms of fewest executions, rather than fewest lines.

For instance, this would be the "right way" to do a repetitive process, and 99 times out of 100, this is what I would do:

```
$counter := 0
while ($counter < 16)
    %Variable[$counter] := $BeatNumber + sin(($counter/16) * 360)
   inc($counter)
end while
```

But this method would be faster to execute. More lines and totally Amateur Hour, but faster:

```
%Variable[0] := $BeatNumber
%Variable[1] := $BeatNumber + .38
%Variable[2] := $BeatNumber + .71
%Variable[3] := $BeatNumber + .91
%Variable[4] := $BeatNumber + 1
%Variable[5] := $BeatNumber + .91
%Variable[6] := $BeatNumber + .71
%Variable[7] := $BeatNumber + .38
%Variable[8] := $BeatNumber
%Variable[9] := $BeatNumber - .38
%Variable[10] := $BeatNumber - .71
%Variable[11] := $BeatNumber - .91
%Variable[12] := $BeatNumber - 1
%Variable[13] := $BeatNumber - .91
%Variable[14] := $BeatNumber - .71
%Variable[15] := $BeatNumber - .38
```

With that said, I should probably test exactly how much time I'm saving. Admittedly, I might be disappointed by the time savings.


----------



## gregh (Nov 28, 2018)

It can be fun to try and get the shortest possible code - Matlab used to run competitions for this - but you are right that readability is important, and commenting is important too.




Mike Greene said:


> Fewer lines is a good goal in general, but sometimes I'll skip line-saving efficiencies just because there are times when the "longer way" is more readable. For me, at least. For instance, I like to be able to see at a glance, _"Oh, here's where I declared the swing slider and here's its range,"_ rather than tracking to arrays where the settings are.
> 
> Also, in certain instances, fewer lines doesn't necessarily mean the script is more efficient. Since my scripts often have pattern players, there are certain instances where there's a ton of stuff going on exactly on a downbeat, so those microseconds can start adding up to milliseconds. I need to trim as much time as possible, so I have to think in terms of fewest executions, rather than fewest lines.
> 
> ...


----------



## kb123 (Nov 28, 2018)

Using inline functions (those not requiring a call statement) is the biggest code generator. Have an extended piece of inline code in a call back and you can generate 100K lines of code without blinking 

For less code lines choose which functions to "call" judiciously


----------



## EvilDragon (Nov 29, 2018)

Mike Greene said:


> But this method would be faster to execute.



Possibly faster but less precise, too, since you're rounding those values from sin() far too much


----------



## Mike Greene (Nov 29, 2018)

EvilDragon said:


> Possibly faster but less precise, too, since you're rounding those values from sin() far too much


Definitely, although a wave that only calculates at 0, 22.5, 45, 67.5 and 90 degrees is already pretty imprecise.  That was just an example I made up to illustrate my point.


----------

