Performance check on windows 11

Gig Performer on Windows
1

Now that I am no longer playing regularly, I have time to play with Gig Performer. I think everyine in this forum for helping me get by while I did not have that free time. I hope my evaluations help return the favor.

At the time my band broke up, the biggest issue I was still having was CPU usage. I’ve spent time investigating that. Here is what I have learned so far.

I have B3 VSTs from Arturia, IK Multimedia and Native Instruments. I used these to see what was going on. I used a new song and simply added the VST to the rack with no connections.
CPU Memory VST
5% 32.9MB Arturia
17% 156.2MB IK Multimedia
0% 240.2MB Native Instruments
Memory usage was determined from differences for the GP instance according to Task Manager. CPU usage is what was reported by GP. Task Manager cliamed usage was less than 1% for all 3. These metrics are for idle VSTs; no notes or tone generation involved.

I did find I could load several Native Intruments VSTs without any change in CPU usage.

I never had time to play with multiple instances of GP until now. My single GP instance was running very close to matching physical memory. In that configuration, I found CPU usage to be cumulative. If I loaded all 3 of those B3 VSTs in a single instance, CPU load would match that of adding all 3 single usage metrics together. So, I decided to spend a little time with multiple instances. I loaded each of these VSTs in its own instance. Splitting keyboards, I was able to play all 3 at the same time. And usage metrics in each instance matched what I found when individually checking each in a single instance.

Bottom line for me, I’m ready to start setting my songs up to run in multiple instances. I need to learn how to keep each instance in sync (on the same song). I need to learn how to quickly and easily initialize my system for a gig. And I will need to learn how to maintain multiple instances when adding, removing and modifying songs. But I now believe the results will justify the effort.

1 Like
2

Additional metrics:

I set up an empty rackspace and added two empty songs. For each of the 3 B3 organs, I added it to song 1 and then to song 2 to see the differences. I deleted VSTs from both songs and added the next. When I was done, GP consumed 70.7 MB more than when I started. GP or one or more of the VSTs appear to possibly have a memory leak. But the results are probably still fairly valid.

Adding Arturia B3 to song 1 consumed 165.3 MB. Adding it to song 2 consumed an additional 152.1 MB.

Adding IK Multimedia B3 to song 1 consumed 250.0 MB. Adding it to song 2 consumed an additional 125.6 MB

Adding Native Intruments B3 to song 1 consumed 305.4 MB. Adding it to song 2 consumed an additional 98.4 KB.

It would appear to make sense to always use an instrument in the same instance and not have it in both. For some of the VSTs, (like Native Instruments), that could result in much lower memory consumption. It also appears that savings will vary from VST to VST.

3

I don’t understand this - you don’t add plugins to songs - you add them to rackspaces. If yo used a single rackspace for both songs, then the extra memory should have been negligible so I don’t quite understand what you did

4

Going down this path of exploration is certainly good and useful, but having done this myself I’ll point out a few things that may save you some head scratching. And maybe one thing about the GP terminology.

As dhj noted above, a Rackspace is the thing you see on the wiring diagram where you add VSTs, and there are corresponding panels where you place your widgets. A rackspace has one or more variations, where the only difference between variations is what the widgets are set to.

A song is made up of one or more songparts, and a songpart is just a reference to a rackspace variation. There are a few additional things to songparts, but for the most part the whole point of songs and songparts is just to have a song-oriented way to point to different rackspaces.

Any time you are placing VSTs you are placing them in a rackspace, period. You can’t place a VST in a song or delete a VST from a song. The song is just a pointer to the rackspace.

Putting that “language” stuff aside, what you’re seeing with the different VSTs is generally “real” with regard to CPU, but not necessarily “real” when it comes to RAM.

Very generally speaking, a “modeled” instrument is going to use a lot less RAM and more CPU, where a sampled instrument will use a lot more RAM and in most cases less CPU.

The Arturia B3 and IK B3-X are modeled, as is Blue 3 (which you didn’t mention but is very popular). The Native Instruments B3 is sample based (as far as I know, I don’t use it).

The various B3s all tend to come with a bunch of effects these days (reverb, amp sims, Leslie sims, etc.) and those will all take additional CPU. I don’t know how Native Instruments handles that.

When you run GP it is generally going to put all of the audio processing on a single core of your processor. If you look at the performance in Task Manager you’re going to want to view all the different cores individually to understand what’s really going on.

If you run multiple instances of GP, generally speaking each instance will have its audio processing on a different core. So you can absolutely get more VSTs working if you use multiple instances. However it’s not simply additive. I spent a fair amount of time testing that out a few times just because I felt like it. I did most of my testing with “well behaved” VSTs, which at the time was mostly Pianoteq and some Melda FX.

By “well behaved” I mean that they took almost no CPU when not playing any notes, and were not ridiculous CPU hogs when doing “normal” things. At the time I was doing that testing I could get 3 instances of Pianoteq in one GP instance without glitching at 48kHz, 96 samples. If I went to 4 Pianoteqs I would get crackling from time to time.

If I put two instances of Pianoteq in each of 3 different instances of GP I could get six instances of Pianoteq without glitching if I disabled “virtual cores”. If I left virtual cores on I could only reliably get 5 instances as I recall.

The only point of running those tests for me was curiosity. The point was to see how linearly capacity would scale with instances. I was wondering I’d be able to run, for example, 8 instances of GP with each having three Pianoteqs playing at the same time, or 24 Pianoteqs total. It was nowhere near that. It was five vs. three, so by going from one instance of GP to three instances I got less than double the Pianoteq capacity. Going to four or five instances of GP didn’t seem to add much for me on that processor at that time.

In task manager I could see which core each instance was running on. I’m oversimplifying a bit, because GP will run different threads on different cores. The UI, for example, generally won’t run on the same core as the audio engine if you’re running one GP instance. If you run more instances of GP you may end up with the UI process of one on the same core as the audio thread of another. At least at that time in my particular case. More instances means more likelihood that the UI of one overlaps with the audio of another on the same core.

Coming back to RAM, Windows does its own thing with RAM.

Just because Windows shows your RAM going up doesn’t mean its going to stay up, and just because it reads low now doesn’t mean its going to read low later. At least that’s my experience. But if you’re not running out of RAM, it doesn’t really matter. If you are running out of RAM then you’re not going to avoid that problem using multiple instances. I expect multiple instances will always consume more RAM than using a single instance, all else equal.

I suspect in your test where you added then deleted VSTs you were seeing oddities in how Windows manages and reports RAM use rather than a “memory leak.” I certainly won’t rule out the possibility that either GP or a VST has a bug where RAM isn’t being released properly, but that wouldn’t be my base assumption given what I’ve observed of Windows reporting in Task Manager in general.

5 Likes
5

@dhj I apologize for the reply delay. Sometimes the real job gets in the way. And I apologize for my erroneous terminology. As @Vindes figured out, I was referring to rackspaces, not songs. I habitually add a new rackspace for each and every new song for many reasons. So I tend to use the two terms interchangeably.

@Vindes, the Native Instruments B3 is a sampled instrument. And it does make sense that it would use more memory and less CPU than the other two. I don’t have Blue 3. So I could not include it in my testing. I have three B3s, each of which has certain features and characteristics that are appealing to me, but, not likely noticeable to anyone in my audience. I didn’t think I needed a forth. :smile:

I have not observed this. @dhj, is that the case? It does appear each instance of GP is using a different core. But it appears to me a single instance always uses a single core and can easily overrun the CPU when too many CPU consuming VSTs are in the same “rackspace” (aren’t you proud of me using the correct terminology and all :smile: )

@Vindes Thank you for all of your insight. I think it will help me figure out how to best set up my new configuration to handle whatever I decide to do post-breakup.

6

Although I’m not @dhj, I can confirm the GP uses multiple threads in one instance, but only one for the audio processing:

1 The audio thread
2 The message thread for the gui
3 (I think the scripts run in a separate thread)
4 Plugins can internally use multiple threads. That’s something GP has no control of

The reason for having at least the first 2 threads is that gui processing must be separated from audio processing. Gui’s tend to do all sorts of things you don’t want to do on the audio thread, because it could introduce crackling for example.
Keeping the gui and audio apart is one of the main headaches in writing plugins.

1 Like
7

Thanks @Frank1119, my only experience with threading resulted in overloading database servers with very little load on my host. So I haven’t had to delve too far into managing threads. Do the various threads get spread across CPUs or do they all run under the same SPU as the application? If they are already spread across CPUs, then where is the performance benefit of running multiple instances of GP?

8

Due to its nature a single thread runs on one cpu at a time. It’s the task of the os to assign threads to a cpu. That doesn’t mean that a thread always runs on the same core: that’s up to the os. An application however can hint the os which type of service it needs, for example the audio thread will be created with a flag indicating that it is realtime/multi media. The os tries to honor that, while selecting a core for that thread (for example not choosing an efficiency-core)

1 Like