Major performance issues with threads in 2020 R2

Targets macOS
1

Has anything significant changed with threads in the 2020 releases? I’ve actually noticed quite a bad degradation in performance from all versions after 2019 1.1.

I have a fairly complex threaded routine that loops through thousands of files and pulls data into arrays to do calculations and populate a listbox.

In Xojo 2019 1.1 this code completes in 5 seconds.

In Xojo 2019 3.2 this code completes in OVER THREE MINUTES.

In Xojo 2020 R1.2 this code completes in 48 seconds.

In Xojo 2020 R2 this code completes in OVER EIGHT MINUTES. It renders my application completely unusable. In addition, I’m noticing constant beachballing while navigating my application after the thread completes in 2020 R2.

Has anyone else noticed this?

2

Is this in the compiled versions of each?

1 Like
3

Compiled or built, the results are about identical.

1 Like
4

Try profiling your code to see where all the time is being spent. Might show something like a call to folder item is taking all the time.

1 Like
5

Can you tell me how to reliably get profiling output?
I tick the menu item, run my projects, and get nothing.
I’ve tried ending the project from the IDE, from the window File/Quit, from the app File/Quit, and never get a list of profiling output.

6

Does your code include StopProfiling anywhere?

In the normal course, you’d check the menu, then simply run your app, then quit it normally to see the profile data.

If you’re not seeing it, it might mean that your app is not quitting normally.

7

If you are on macOS try Instruments for profiling. I have a series on Instruments on my blog: https://www.mothsoftware.com/blog/blog.php?search=instruments

2 Likes
8

Double check the “close” event of the App object and make sure you’re not calling the “Terminate” API or any other API to close your application instantly.

If your application is App Sandboxed, try following this guide here.
https://www.ohanaware.com/blog/202040/Profiling-App-Sandbox-Applications-with-App-Wrapper-3.html

9

The profiling was of no help. It just told me what I already know — my thread is taking an insane amount of time to run, but it doesn’t show me why or where or anything like that. I’m very disappointed because I cannot use Xojo 2019 on my M1 MacBook Air since no plugins will load. 2020 R2 was running so well and I really thought it was going to be great, but now I find I cannot compile or distribute my apps with 2020 R2, I have to go back to 2019 R1.2 and can only compile from my iMac. I really hope this is on the Xojo team’s radar, because it’s definitely a major problem.

10

No, it won’t be because it’s YOUR job to find the root cause of the problem. Start by eliminating parts of your code to see where the problem is.

Did you see my comment on Instruments?

Access to a lot of folderitems should be faster in 2020r1 because of the following bugs:
54439 Framework » macOS FolderItem: optimized child by index APIs to match performance before the switch to using the newer NSURL APIs.
59275 Framework » macOS FolderItem memory is now cleaned up immediately after FolderItem.Parent or FolderItem.Name is called instead of being released after the main loop iteration runs.

FileListMBS has the property YieldTicks to yield. Which works fine for a medium number of files (50k or so).

1 Like
11

It’s definitely something with folderitems and reading files. For example, I made a test to load a listbox with folders, and expanding a folder in the listbox reads corresponding files (about 1200 files) and then adds rows for data from each file. This takes <1 second on 2019 R1.2. In 2020 R2 it takes 9-11 seconds.

I’ve systematically commented out my code in chunks and ran it to determine what slows it down. It’s specifically with looping through a folderitem, reading the contents with a TextInputStream and then closing the file. This process is about ten times slower in 2019 R3.2 and newer (all the way to 2020 R2).

In fact, I just did another test. Simply opening a folderitem now takes about 5 times longer. I’m simply looping through a list of 1000 files, calling TextInputStream.Open(f.item(i)) and then immediately closing the file. Not reading it, not manipulating it, and calling no other code. This simple tasks takes 8 seconds to complete in 2020 R2. It takes less than half a second in 2019 R1.2.

It has nothing to do with my code. Opening files is much, much slower now.

EDIT: I’ve made a new post about this - it isn’t threads that are the issue, it’s FolderItems and/or TextInputStreams. You can close this thread.