Performance comparison Kontakt 5.8 vs HISE

[Stroggan]

I just finished porting my guitar library from Kontakt 5.8 to HISE and was positively surprised about the memory and CPU usage of HISE(compiled to 64 bit VST)

Memory usage Kontakt: 190MB
Memory usage HISE: 103MB

CPU difference while playing the exact same thing:

The timer in kontakt is set to 1ms resolution while the one in hise is 4ms, having them set at the same value results in about twice the cpu usage for kontakt instead of three times. but the HISE version has arrays of twice the size compared to the kontakt script, so it iterates over more data per timer tick.

Hopefully I don't encounter any issues because this really makes me want to go 100% HISE in the future.

[Christoph Hart]

But both HISE and Kontakt got beaten by the Monitor FX though :)

BTW are you using HLAC? If not, expect memory to go down 50% because it can use 16bit preload buffers.

[Stroggan]

If saving as Monolith means it is HLAC then yes.

[ossian1961]

@Stroggan said in Performance comparison Kontakt 5.8 vs HISE:

Hopefully I don't encounter any issues because this really makes me want to go 100% HISE in the future.

...and you're forgetting most important thing, Kontakt can't create a real plugin ;)

[Stroggan]

I did encounter an issue :(

I was running most of my logic in a defered script, which seems to work great 99% of the time.
But I noticed today when I rendered an example at full speed offline, that the output wasn't exactly the same as live playback.

I rely a lot on the "Engine.getUptime()", is it possible that the result from this timer gets scaled somehow when used in the gui thread and playback is faster than realtime?
Maybe I should just make my own counter variable and increment in the timer callback?

[d.healey]

@Stroggan All realtime stuff should be put in a script that isn't deferred.

[Stroggan]

Sure, in general, but I don't need 100% instant response and what I am doing works in all but this edge case so far. Maybe running this deferred has some potential downfall I'm not aware off.

[Christoph Hart]

If you don't defer a script, then the Engine.getUptime() is sample accurate down to +-8 samples because in its default setting which can be changed by the macro HISE_EVENT_RASTER, HISE rounds every sample position for events (notes and timers) to 8 samples to apply SSE optimizations and downsample the modulation control rate. This introduces a "jitter" of 90 nanoseconds at 44kHz, so it should be neglible.

If you defer a script, the Engine.getUptime() function will return the exact value that the audio thread is currently using, which can be any value in the future because you don't know exactly when the deferred callback is executed, and in the case of offline rendering this can have drastic effects.

So bottom line, whenever you need "musical" timing, don't defer the script. This function is rather for stuff like "update a button on the GUI if you press a note" type of applications.