Running IDE in Linux vs. Wine

Hello,

a few months ago I switched from Windows to Elementary. My Computer is a i5-3550S Desktop with Intel HD Graphics and 8 GB RAM.
With Elementary freya (32 Bit) the IDE was very slow, but at last usable.
With Elementary loki (64 Bit) the IDE is nearly unusable.
So I install Xojo under wine for a short test. In this test i added a generic button to the window. Then I copied this button in positioned it in the window. I did this under Xojo-Wine and Xojo-Elementary. Under Elementary it was not possible to position more than 12 buttons in the IDE. Under Wine i could easily position more then 48 buttons. In both cases the CPU usage was about 25%.

IDE with buttons under Elementary. The IDE becomes unusable:

IDE with buttons under Wine. Still able to add an position more buttons:

I also tried Ubunto xfce with nearly the same result. Where is something totally wrong with the IDE under Linux. This should not be the case for a payed application.

I use 2015R1 and 2016R3 in LiteLinux (32 bit Ubuntu 16.04, xfwm4)

2016R3 is faster than 2015R1, but with each added object it becomes slower (both)

Hi @Maik Sbiegay, @Axel Schneider and all other Linux IDE users

Try this on your Linux system to speed things up:

sudo cp /etc/fstab /etc/fstab_prexojo
sudo gedit /etc/fstab

(of course, any editor that you are comfortable with will work)
Add the following lines at the end of the file :

tmpfs /tmp tmpfs defaults,noatime,size=1G,mode=1777 0 0
# if you have 12GB or more RAM, you can increase that size=1G to size=2G
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

Additionally, the swappiness value determines how much data is written to the virtual memory on the hard disk drive, which can slow your system down. Edit the value in the /etc/sysctl.conf file:

sudo cp /etc/sysctl.conf /etc/sysctl.conf_prexojo
sudo gedit /etc/sysctl.conf

Scroll to the bottom and add the following two lines:

# Decrease swappiness value vm.swappiness=2
After these changes are made, reboot the Linux system / VM.

These changes have made a dramatic improvement in the IDE’s performance under Linux for me.

BTW - if you need to “undo” the changes, simply move the _prexojo files to their original locations and reboot to return to normal.

Thanks to @Jose Navarro for discovering this link to /tmp performance.

Thanks.
Unfortunately, there was no change on my system.

It still takes up to 3 seconds before a context menu appears in 2015R1.

But I have to say it is an old Notebook.
(Samsung SA11, Core2Duo T5800 2.00GHz, 4GB RAM, G98M [GeForce 9200M GS], 120GB SSD).

If you only have 4GB then taking away one for this change will have other results in performance. I guess that I should have warned that you really shouldn’t do this unless you have 6GB+ of RAM.

I haven’t tried, but what if you make this change:

tmpfs /tmp tmpfs defaults,noatime,size=512K,mode=1777 0 0

4GB is Maximum

Understood - but can you retry the setting with that change in the tmpfs size from 1G to 512M (sorry, I typed 512K above).

tmpfs /tmp tmpfs defaults,noatime,size=512M,mode=1777 0 0

Thanks,
The notebook is otherwise not slow, there is no other app that is as slow as the Xojo IDE.

If you ‘strace’ an IDE instance, you will see a large number of calls to things that use the tmp folder. By moving that to RAM, it really speeds things up. On a system with a 7200RPM drive, this was obvious for a couple of other apps I use - specifically Nuke and Blender.

I also now understand why my normal Linux boxes aren’t as slow as many are seeing - we use PCIe m.2 SSD modules on all of our test systems.

I’m trying to get statistics with strace and this is the result. Mostly, files inside ~/Xojo and xojo/Xojo Resources are accessed by IDE. IDE only make few call to /tmp directory.

System call usage summary for 32 bit mode:
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 46.31    0.023343        1796        13           waitpid
 34.57    0.017427           0     49389         8 read
  6.61    0.003333         115        29         5 unlink
  6.61    0.003333         119        28           fsync
  2.72    0.001370           0    159648         2 poll
  1.29    0.000648           0    169888    156821 recvmsg
  0.50    0.000251           0       978           munmap
  0.40    0.000204           0     60643           _llseek
  0.20    0.000100           0     14677      1734 access
  0.14    0.000073           0      1389           mmap2
  0.13    0.000068           0      3590       501 open
  0.12    0.000058           0     22393      3537 lstat64
  0.10    0.000052           0     12567           writev
  0.05    0.000027           0      1487           write
  0.05    0.000024           0      3974           _newselect
  0.05    0.000023           0      3973      3973 ioctl
  0.04    0.000022           0      7573           fstat64
  0.04    0.000021           0      3897      1704 stat64
  0.02    0.000012           0       863           brk
  0.02    0.000008           0       680           shmat
  0.01    0.000006           6         1           time
  0.01    0.000006           0        90           fstatfs64
  0.00    0.000000           0         2           restart_syscall
  0.00    0.000000           0      3109           close
  0.00    0.000000           0        22        16 chmod
  0.00    0.000000           0         4           utime
  0.00    0.000000           0         4           rename
  0.00    0.000000           0        11           pipe
  0.00    0.000000           0         1           gettimeofday
  0.00    0.000000           0        52           readlink
  0.00    0.000000           0         1           sysinfo
  0.00    0.000000           0        10           clone
  0.00    0.000000           0        22           uname
  0.00    0.000000           0       237           mprotect
  0.00    0.000000           0       757           getdents
  0.00    0.000000           0        12           flock
  0.00    0.000000           0         3           sched_yield
  0.00    0.000000           0        14           rt_sigaction
  0.00    0.000000           0         7           rt_sigprocmask
  0.00    0.000000           0        11           vfork
  0.00    0.000000           0         3           ugetrlimit
  0.00    0.000000           0         7           geteuid32
  0.00    0.000000           0         2           getresuid32
  0.00    0.000000           0         2           getresgid32
  0.00    0.000000           0        43           madvise
  0.00    0.000000           0       538           getdents64
  0.00    0.000000           0       394           fcntl64
  0.00    0.000000           0       424         4 futex
  0.00    0.000000           0         1           sched_getaffinity
  0.00    0.000000           0         1           set_thread_area
  0.00    0.000000           0         1           set_tid_address
  0.00    0.000000           0        36           fadvise64_64
  0.00    0.000000           0         1           set_robust_list
  0.00    0.000000           0         3           eventfd2
  0.00    0.000000           0         4           socket
  0.00    0.000000           0         2         1 bind
  0.00    0.000000           0         2         1 connect
  0.00    0.000000           0         1           listen
  0.00    0.000000           0         3         2 getsockname
  0.00    0.000000           0         2         1 getpeername
  0.00    0.000000           0         5         1 recv
  0.00    0.000000           0         8           setsockopt
  0.00    0.000000           0       677           shmdt
  0.00    0.000000           0       680           shmget
  0.00    0.000000           0       680           shmctl
------ ----------- ----------- --------- --------- ----------------
100.00    0.050409                525569    168311 total

I tried the tip from Tim and moved the temp folder to RAM. For me it brought no speedup mainly because I’m already using a SSD.
My main concern is that with the switch from 32 Bit to 64 Bit on elementary the performance of the IDE even got worse.
The IDE seems to use only one core and when moving components around the CPU usage goes up to around 90% for that core. So what causes the IDE to use so much CPU power for this simple task?

[quote=292451:@Tim Jones]If you ‘strace’ an IDE instance, you will see a large number of calls to things that use the tmp folder. By moving that to RAM, it really speeds things up. On a system with a 7200RPM drive, this was obvious for a couple of other apps I use - specifically Nuke and Blender.

I also now understand why my normal Linux boxes aren’t as slow as many are seeing - we use PCIe m.2 SSD modules on all of our test systems.[/quote]

I think I know what do you mean. I’ll try to implement that and see what happens then.

the IDE has never used more than 1 core
it spikes because while on screen is “simple” under the hood there’s actually a lot of work going on with redrawing as you drag etc
graphics suck up a lot of horsepower

@Norman Palardy. I see a lot of call from Xojo IDE to unix socket via poll , recvmsg, etc that similar to app built with xojo. But, IDE make a constant call to unix socket either in idle or not. Whereas other app (simple app built with xojo) only call to unix socket when in focus or receiving an event.

The IDE has a listening socket since you can control it from an external program

external program? I don’t know about that. Can you give me a clue?

Xojo/Example Projects/Advanced/IDE Scripting/IDECommunication/IDECommunicator.xojo_binary_project

Hi Norman,

when running the IDE under Wine it doesn’t take the same CPU power to do the same job as under Linux. So where is the difference? What consumes so much CPU power to do such a “simple” task under pure Linux?

No idea
I never use the IDE under Wine

Thank you Tim