Xojo IDE Sluggishness on Linux - Redux

Rather than necro-ing an old thread, I’m starting a new one.

I’ve continued to track when and where the sluggishness starts to occur on Linux and it is most definitely related to running your project in the debugger multiple times in a single IDE launch session.

I ran another test overnight -

  • Launched the IDE, loaded that project, but did not perform any debug runs.
  • I did edits, copy/paste, Tab changes, but did not run, for over 4 hours.
  • I let the IDE sit untouched until this morning.
  • I just tested a bulk copy/paste of 2 controls from one window to a new window with no issues. I was then able to quit without getting the force quit warning.

This is most definitely still related to the number of times that a project is run in the debugger.

I’ve realized what has been happening on my newer test systems running Ubuntu or Mint - the RAM-based tmp setup in /etc/fstab had gotten clobbered at some point during the updates. We’ve batted it around a few times last year, but I’d completely forgotten it.

Add these lines to the bottom of your /etc/fstab file (use size=1G if you have less than 6GB of RAM):

[code]tmpfs /tmp tmpfs defaults,noatime,size=2G,mode=1777 0 0

tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0
tmpfs /var/log/apt tmpfs defaults,noatime 0 0[/code]

Next, adjust swappiness in sysctl. Edit /etc/sysctl.conf and add this line to the end:

swappiness=2

Reboot and enjoy the IDE again.

Tim,

Thanks for the info. I recently went all-in with Linux and have had a heck of a time dealing with the Xojo IDE slowing down over time. I have resorted to exiting the IDE periodically just to keep my sanity. Since I use the remote debugger constantly for Raspberry Pi development, I didn’t see that the debugger was at the center of this issue. I just figured the Xojo IDE was at fault.

Would you mind explaining what the modifications you recommend actually do? How did you figure out that the Xojo IDE slow-down issue was related to something missing from /etc/fstab???

I’m new to Ubuntu and I hate to just cut-and-paste modifications into my system that I don’t yet understand.

-Wes

PS. My system has 8Gigs of RAM. How does the total RAM in your system relate to “size=”? Is there some rule-of-thumb at play here?

Sure - Xojo uses the /tmp folder for a lot of work during a build or debug run. By moving it to a RAM disk, you remove the I/O bottleneck. Also, the vm.swappiness is a value (0 = off to 100) that says “when RAM uses all but X percent of ram, start swapping to disk.” By setting the number low, you alleviate unnecessary swapping unless memory is almost fully consumed. On a system with 8GB or more, I’ve actually started setting the value to 0 to turn off swapping. I’ve I’m running a desktop system with 8GB or more and start swapping - something is seriously wrong and THAT problem should be looked into.

This combination gives Xojo more breathing room during runs and also seem to resolve the RAM use causing swapping (which is the true causes of slowdowns over more than one or 2 debug runs).

As for the size= setting, remember that you are using that amount of system RAM for the /tmp folder, so it will no longer be available for OS use. This is why the comment about only using 2G if you have more than 6GB of system RAM assigned/available.

Thanks Tim,

I’m pretty excited to try this. I’ll report back once I’ve tried it and spent some time editing/debugging in Xojo.

-Wes

PS. Since your configuration changes aren’t Xojo specific, will I see performance improve in other applications too? What Linux tools are available to let you monitor swapping and RAM disk usage?

I suspect you’ll see a difference across the board. One note - there is a type in the swappiness line. It should read:

vm.swappiness=2

As mentioned, you can play with values from 0 (off) to 100 (always swap - NOT recommended :slight_smile: ).

I was wrong again … :S

After some serious experimentation over the past week, the issue is definitely related to the UNDO/REDO engine (if it’s not, then there’s something far more nefarious going on that even strace can’t follow).

Starting the IDE, loading my project, and letting is sit idle for 24 hours - no memory growth
The same, but running the project 10 times - very limited memory growth (100MB or so)

However, when I started editing, copy/paste, control resize, control moving, adding new windows, adding new controls, the memory started ballooning - up to 4.2GB on Linux and almost 8GB on macOS - at this point, I had to kill the Linux IDE. I didn’t check on Windows since I was trying to compare the experience on Linux to macOS.

The ONLY thing that reasonably comes into play there is the UNDO/REDO stack. While the tmpfs and swappiness changes help with things like precompiling the plugins, it doesn’t sort this issue.

Undo does a LOT of state preservation

Good to know… Even after making the changes you suggested, my system still shows down terribly after a short period of time.

Sure hope they get this fixed. I’m loving working in a Linux environment but the Xojo IDE doesn’t seem to share my enthusiasm for Linux.

I don’t think it’s the undo engine.

For me, I can grow the memory with these steps:

-create a new project.
-drag a scrollbar to the main window
-press TAB 100 times (focus should go between the control and the window)

Memory grew by about 150M (with no editing of any kind)

You can also just click back and forth between the control and window or any two items in the navigator (except for the “controls” items of two windows).

Adding an event and typing randomly will also grow memory quickly (autocomplete on or off)

[quote=432758:@jim mckay]drag a scrollbar to the main window
press TAB 100 times (focus should go between the control and the window)
[/quote]
The UNDO stack actually tracks all of those things :smiley:

[quote=432759:@Tim Jones]The UNDO stack actually tracks all of those things :smiley:

[/quote]
I can’t “undo select window” “undo select control”
I’m not adding or moving or editing anything. Just selecting…

Or do you think it’s generating an “undo state” just in case an edit is made?

That’s what I see. It appears to be trying to track “where” you are not just “what” you did.

Changing build setting doesn’t grow memory and those settings are undoable…

I would more likely suspect something about the IDE rendering not releasing images or something like that.
1.5M for a change of focus is a big chunk for an undo. Not that big if you’re talking a graphics related problem.

Here’s another experiment… add a line of random text to an event.
use the cursor keys to move around in the line and watch the memory usage grow. (no editing, no navigating around the project)

From what strace indicates, SOMETHING is being stored any time your move your edit point or change control focus. This would match everything that you are illustrating.