Memory usage: Xojo IDE

General
1

I can’t fail no notice memory usage is insane for an IDE, its about the same as a 3D exterior scene!
The Below shows QT Creator running dlltest and is the batch creator 3 debug, both very similar programs, but Xojo is running at nearly 1 gb were as QT is only 108meg
even when Xojo isn’t debugging the memory creeps up every time I run and is even worse with the reference guide open
Its not just Windows, Linux gradually slows down

I’ve seen this with the software I beta test for and its usually memory leak, it seems weird an IDE should use so much memory, Visual Studio never goes passed 143meg with a project bigger than my Xojo one

2

I’ve noticed some of this too, though (with me at least) the slowdowns/freezes happen far less frequently than before the last major update.

3

I reckon the memory creep up by about 4% each time I run a test, its a shame I have no older versions to compare

My app is nothing special just buttons, text fields and a few lists… I do have the MBS components, I don’t know if they maybe causing it?

4

Wow, if I take out the MBS plugins it drops to 227meg and never gets any higher
(there’s no MBS plugins used in the project)

5

It has been stated in the past that the IDE loads all plugins at start up to make them available to you. So it is best to only have those plugins you need in place when coding.

6

I shall do that, I’m fairly new here so I never seen any mention of only using them when needed, thanks

7

Also, plugins take a long time to load. All the reasons not to have the whole bunch in for nothing…

8

I just live with it. I work with multiple project that may or may not use any number of plugins. It would be a PITA trying to keep up with what to remove or add to the plugins folder. It would be nice if there was a better way to manage plugins.

9

I was going to ask if anyone had made a plugin manager, this kind of answers that question.

10

Processes, like the IDE, can load DLL’s / dylibs dynamically but you can’t force a process to unload them.
So once you load one you’re stuck with it until the entire process exits.
The very BEST we could do is see that a new plugin had been added to the PLUGINS folder and load it - but we can’t drop or remove them from memory.
Wish we could but that’s the reality of how dylibs etc work.

There are some REALLY wild ideas about using “some other set up” to make it possible but they’re just wild ideas at the moment and nothing more.

11

That is one of the things that I hate the most about esoTalk: you have to dig to see if someone is new.

Sorry if I sounded a bit rude there.

12

No worries Bob, I replied on my old Linux laptop which has keyboard issues so my reply was a bit short and condensed

So you didn’t come across rude at all, I’m grateful for all the help you guys have given me over the last month or so :slight_smile:

13

[quote=135353:@Norman Palardy]Processes, like the IDE, can load DLL’s / dylibs dynamically but you can’t force a process to unload them.
So once you load one you’re stuck with it until the entire process exits.
The very BEST we could do is see that a new plugin had been added to the PLUGINS folder and load it - but we can’t drop or remove them from memory.
Wish we could but that’s the reality of how dylibs etc work.

There are some REALLY wild ideas about using “some other set up” to make it possible but they’re just wild ideas at the moment and nothing more.[/quote]

What I’ve never understood is why the IDE needs the entire plug-in in memory. It definately needs some of the data to operate but wouldn’t this be a perfect example of using a helper process which could load the libraries, extract the required data and then cache the data to disk for the IDE to use?

14

It actually READS the plugin to generate that data.
To read the plugin it has to load it - and now you have no option but to have it in memory.
Once its done this once it does cache that data - but it still needs to load that data and with a lot of plugins thats a lot of data.
The DLL/SO/Dylib is only a portion of whats in memory.

15

Hi Norman,
under Windows there is the FreeLibrary() function to free the loaded dynamic-link library and the associated memory used.
I don’t know if the real problem for the memory usage it is related to DLL’s but for these elements there is, possibly, a solution.

I see under Windows that after a debugging session the IDE does not free the memory used so after each debugging the total amount of memory used grows.
My perception is that this behaviour must be investigated because maybe it’s masking some sort of memory leak.

Regards.

16

I wonder if there is scope for a ‘simple’ IDE-level list of ‘plugins to include’
Im thinking of the way VB6 used to manage OCXs and OLE objects.

There was a list of all the available ones, and a tickbox to say which ones you wanted to be able to use.

If that list was reviewed when the IDE loaded up, Xojo would only mount the required ones.
If you found you needed on later, revisit the list, tick a box, up it loads.
If you later dont need it, no worries, its already loaded but wont be unloaded until the IDE closes.

17

+1.

That would be very nice and convenient. Feature request?

18

[quote=135482:@Maurizio Rossi]Hi Norman,
under Windows there is the FreeLibrary() function to free the loaded dynamic-link library and the associated memory used.
I don’t know if the real problem for the memory usage it is related to DLL’s but for these elements there is, possibly, a solution.

I see under Windows that after a debugging session the IDE does not free the memory used so after each debugging the total amount of memory used grows.
My perception is that this behaviour must be investigated because maybe it’s masking some sort of memory leak.

Regards.[/quote]
FreeLibrary doesn’t force it to unload - it marks it as unused but the current process which may result in it being unloaded
MSDN says
Frees the loaded dynamic-link library (DLL) module and, if necessary, decrements its reference count. When the reference count reaches zero, the module is unloaded from the address space of the calling process and the handle is no longer valid.

I’ll reiterate

[quote=135476:@Norman Palardy]It actually READS the plugin to generate that data.
To read the plugin it has to load it - and now you have no option but to have it in memory.
Once its done this once it does cache that data - but it still needs to load that data and with a lot of plugins thats a lot of data.
The DLL/SO/Dylib is only a portion of whats in memory.[/quote]

19

Could you not just provide a visual shortcut inside the IDE which loads the plugin if its actually used?
like a thumbnail (which the plugin developer would do) and a browser window

20

We don’t know ahead of time what new project you’re going to start & whether or not you’ll use those 57 plugins in the plugins folder. We’re good but not prescient.
So while the project you have open right now may not use them, the one you start in 30 seconds might.
We can’t load on demand because - we don’t know whats IN the plugin until we load it :slight_smile:
So if you type someMagicMethodMBS we have no idea what plugin that is etc until we load them.
And once we load them then the issue of unloading them arises and we’re back at the beginning of this thread :stuck_out_tongue:

Seriously this IS something we have thought about how to change and we’ve spent actual time looking into this.
And every time we’ve gone round this particular circle we come back to “without rewriting the ENTIRE plugin loading process on each platform there’s nothing the CURRENT process can really do better because of how shared libraries work and whats required in the IDE to make them available to developers to use”

Reinventing that process just ISN’T that high on the TO DO list