I’ve just been startled by the amazing high CPU usage when using the RM8 (8.1.5.0) Edit Note panel on my iMac. This is particularly obvious when adding additional text to existing text, but I suspect it is indicative of some very inefficient processing going on.
Has anyone else noticed this? Is this Mac specific, or do Windows users also notice something similar?
To illustrate the problem, I created text comprising 30 lines each of 40 characters. Then I keyed a new line of the same 40 characters. By the time I had finished keying in, only 7-8 of the new characters were displayed on the screen and it took well over another 90 seconds for all the keyed in characters to be displayed. During the whole of the 90 plus seconds, RM was using 100 percent of one of the 4 cores of my iMac, and then it dropped to using relatively little. To say that I was staggered is an understatement. I have raised with support.
In building up to that test, I noticed that the time taken did increase with the size of the existing text.
Clearly something appears to be very wrong with the handling of text input, and maybe it is also indicative of why other aspects of using the Edit Note panel - such as selecting and pasting - so difficult to use and slow - slow - slow.
No, you’re not alone. At the moment I’m doing nothing on RM8 except it has a couple of small databases open and Windows Task Manager reports 10-15% CPU and 15% GPU utilisation. RM7 is also open with two small databases and taking around 2% CPU, 0% GPU.
I had noticed the Note Editor slogging away some weeks ago while running some experiments with different character sets. Thought I had reported it somewhere but damned if I can find it.
I more or less duplicated your test but used a lorem ipsum generator for the 1200 characters. My typing speed is slow but I can rattle off a “Now is the time…” and, while resource use spiked, the Note Editor display was close behind my keystrokes that it did not bother me.
Pasting in 12,000 characters (about 1800 words of lorem ipsum), however, triggered a delay of many seconds and spiked CPU to 25-35%. However, repeating the process with the same text from the Windows clipboard gave a near immediate response. On another test with different clipboard content but about the same size, it took 29 seconds from pasting into the empty Note for the Editor to display it.
I’ve not seen an editor so slow since the days of my Radio Shack Color Computer and, I daresay, it was a lot faster!
No, I am not using a ‘blazing fast” M1 iMac but a late 2014 one. That has 16GB and a partial SSD, but should be more than fast enough for entering text. Certainly, looking back into history, it still normally seems very responsive and fast enough to me. If it was blazing fast, the issue wouldn’t be as noticeable.
It is interesting that TomH also notices something similar on Windows, as I’m sure his PC is a little more current. So it seems it may not be Mac specific.
I have the same problem since moving to RM8 but not before on Mac OS Catalina. Plenty of spare everything normally on my machine. have also sent to support and awaiting substantive reply.
Thanks for making me realise its not at my end.
On my MacBook M1, I have three apps open with no activity. Here are the percentages of the CPU being used: Lightroom 1.2%. Photoshop 1.3%. RootsMagic 20% With activity, RM will jump up close to 50%. So even sitting idle, RM is using a lot of processor.
My specific problem report of the CPU load from the Edit Note panel has been accepted and passed to development, but I’m sure this is really a specific example of a much more general problem affecting a number of areas.
It is almost as though in some areas RM8 is too busy to accept any input as quickly as it should and then too busy to process the input and display the result as speedily as it should.
For example, although hardly a most urgent problem, I am amazed at how slow moving round my directory is when I find and then import my RM7 file into RM8. It can take several seconds to make each move up and down the directory hierarchy - that is, selecting a directory or file and then using the open button. (Double clicking to select and open often opens the wrong directory or file, depending on whether one is at the bottom of the hierarchy or in the middle, so this is almost unusable.) This is another area where things are really really wrong. The directory and data will be resident on the SSD, and such operations in all other apps, including RM7 under CrossOver, are ‘instantaneous’.
Well, all is not as it seems. The very slow performance when moving round the directory to find an RM7 file to import is because RM8 is also searching all my directories, RM and non-RM, for any existing RM7 files to list for me to select one. This is a CPU bound process - yes, apparently - and takes quite some time, so my simultaneous efforts to use the directory browse function at the bottom of the panel to directly select the file to be imported inevitably takes quite some time and RM8 can’t keep up with my touchpad usage. Once RM8 exhausts all directories and completes its search for RM7 files, then the browse function reverts to the sort of speedy responsiveness that one should expect. So, it is the unnecessary automatic searching of the disk that is the cause of the problem - plus the CPU overhead that RM8 seems to require for any activity. Another excessive CPU example.
Another example of heavy lifting when there needn’t be is the Person Search - Advanced on the single criterion “Number of children greater than 10”. It took a couple of minutes to get results from a database of around 190,000 people using 8.1.4 on Win 10. The progress stuck at 99% for the longest time but CPU usage was low during that stall. Then it shot up to 30% along with GPU soaring while, I suspect, it was rendering the display output. Now this is on a 5-6 yr old laptop with an i5 CPU and ample RAM - it’s not at the bottom of the heap. RM7 took about 45 seconds to mark people for a group.
The above was drafted yesterday. Today, the marking and display of groups is much faster. I’ve no idea what has changed except that I am aware that SQLite does automatic optimisations based on how a database is used. Perhaps that has something to do with it.
I saw @JP1’s comment that his report was accepted by development in Jan. 2022. Here it is Feb. 2023, I’m running version 8.5.0.0 on macOS Catalina, and when a note has even a couple sentences, typing more text sends the CPU to 87% and the keystrokes take more than a second each to show up. Typing a whole sentence is very painful. This is such an egregious problem, I have to believe a little software development effort could make a big difference. Even if not, it would be interesting to hear the source of this performance issue (speaking as a developer).