From: Matthew O. <le...@us...> - 2024-08-14 22:07:34
|
So the issue resides with the macOS java virtual machines. I had two JDK directories within /Library/Java/JavaVirtualMachines, one I installed to run jEdit, zulu-22.jdk (or temurin-22.jre, I tried them both), and one that was recommended by the Mathworks folks for running Matlab, amazon-corretto-11.jdk. If I remove the zulu/temurin directory such that only the amazon-corretto directory resides in the /Library/Java/JavaVirtualMachines, then jEdit hypersearch works as expected. I am not sure what is ultimately going on here. On other platforms, jEdit is fine with alternate vendors/newer versions of the JDK/JRE. But on macOS, those alternate vendors/newer versions are problematic. I don't think my Matlab installation altered any system settings, as I have tried jEdit 5.7 on a few different systems and only one has Matlab installed (this is also the only one with Java 11 installed). i alternately removed the amazon-corretto-11.jdk directory from /Library/Java/JavaVirtualMachines, leaving only zulu-22.jdk, but that configuration again produced the anomolous hypersearch behavior. --- **[bugs:#4135] Slow HyperSearch Performance on macOS with Large Files and Queries** **Status:** open **Group:** Regressive (new to devel) **Created:** Sat May 25, 2024 12:31 AM UTC by Matthew Orzewalla **Last Updated:** Wed Aug 14, 2024 09:25 PM UTC **Owner:** nobody **Attachments:** - [activity.log](https://sourceforge.net/p/jedit/bugs/4135/attachment/activity.log) (17.4 kB; application/octet-stream) I have been observing slow hypersearch performanc on macOS for a while now, but wanted to wait for a preview of 5.7 to see if performance improved. >From what I can tell, it began with the switch to Java 11, but I'm not positive that is the root cause. The bug has been observed on both Intel Macs and ARM Macs Steps I use to reproduce: 1. Download the plain text copy of Death Valley in '49 from Project Gutenberg here: https://www.gutenberg.org/ebooks/12236.txt.utf-8 2. Install and start up a fresh version jEdit 5.7pre (no prexisting jEdit user directory) from the version posted in this thread: https://sourceforge.net/p/jedit/bugs/4123/. On my system java-version lists: openjdk version "21.0.2" 2024-01-16 LTS OpenJDK Runtime Environment Temurin-21.0.2+13 (build 21.0.2+13-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.2+13 (build 21.0.2+13-LTS, mixed mode) 3. Open the text file (pg12236.txt from the download on my system) in jEdit 4. Perform a search with Ignore Case and HyperSearch selected of the word "death". The 106 results should be returned fairly quickly 5. Perform a search for the word "from". The 625 results will eventually be returned, but it beachballs my system for about 50 seconds. Performing a search for the word "the" beachballs my system for longer than I am willing to wait. I can perform a search of the same file for the word "the" on a Windows install of jEdit and return the 15,733 results in less than 3 seconds (the Windows About jEdit screen lists, "jEdit 5.5.0 server mode, using Oracle Corporation Java 1.8.0_391). I am uploading the activity.log file., but I didn't see anything indicating the slow performance within the file. Let me know if there is any other information I can provide that can help diagnose the root cause. At first I had thought that it had something to do with docking or undocking the HyperSearch window (with docked causing slow performance), but then I went back and did some dedicated testing and found that it is slow undocked as well. It also seems that if I do more searches and work my way up to larger returns that the slowness subsides, as if it is slow allocating memory to the process, but once that memory gets allocated it is no longer slow. Thank you for your help in this matter. --- Sent from sourceforge.net because jed...@li... is subscribed to https://sourceforge.net/p/jedit/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/jedit/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |