ReggieCarey

Thanks for the suggestions and a path to diagnosis. Here are my results: I've got no removable drives right now and nothing attached via USB. I actually tried launching Cura with and without having the printer USB attached. There was no difference in the slowness or CPU utilization. I then tried launching with and without having WIFI active. That had no effect. Also, Cura wants to listen on some port and I get asked each time. I've launched with and without allowing this ability to listen on some port. In all cases, the performance is still laggy and the CPU utilization is still at or above 100%. For reference, when I terminate the program or prior to launching, CPU utilization sits at around 5% or less. From an information standpoint, none of the suggested things to try had any effect on the application performance or CPU utilization. I'm wondering if I should go ahead and push towards compiling the code locally and utilizing a profiler to identify the problem code block. Does any one who commits, work on a MacBook at or newer than my vintage computer? If so, do you experience the performance issue? Are you running the latest patched macOS version from Apple? B.T.W. The previous version of Cura 2.6.69 works relatively well on my computer (it's got serious font issues though). Reggie

MacBook Pro 2013+ 16BG RAM macOS High Sierra 10.13.5 Lulzbot Cura 3.2.21 Lulzbot Mini USB Attached. My computer works fine doing even complicated things like deep learning tasks, numerical analysis, 3D rendering, software development in Java, Python, C, C++, interacting with my various USB attached SBC's, sensors, Arduino's, etc. Cura 3.2.21 is Unacceptably Slow - uselessly slow Statements like "It loads fine on my Mac" are completely useless to the community. Also, statements like "re-install your operating system" are equally useless. This is a relatively simple piece of software that is suffering from a critical software design flaw. Sitting idle on my computer with nothing else running, and no projects loaded, it's burning 100% of a CPU. It's out of the box having done nothing more complex than selecting the Lulzbot mini as the default printer. Navigating the user interface results in lags in responsiveness in the seconds for any simple action like moving the mouse from tab to tab. I don't even want to contemplate what will happen when I try to load and STL file. I started to look at the source code and notice that its utilizing wxPython for a GUI interface. Core committers should run the profiler to find the tight loop. Likely, its a loop incorporating the GUI event thread. Is the code busy checking for input from the USB and then checking for events on the event thread? I recognize that my version may be altered by the Lulzbot folks but I see from this forum that the problem is apparently pervasive. Reggie