Opening files from folders with deep subfolders can be slow #83
Comments
Prevents hidden folders from being scanned. The chances of people storing ontology documents in hidden folders is pretty remote (we hope!).
|
When an ontology is opened a catalog is generated (and a folder, and subfolders, searched) whether or not the ontology has imports. Tim (@stdotjohn) do you know if this can be done lazily? |
|
I suspect that the cause of this problem may be different than what you This problem is easily fixed by preventing DTD processing. There was a I have not seen the catalog implementation get into any trouble other This could be very quickly settled if the user sends a thread dump so we -Timothy On 08/01/2014 04:36 PM, Tania T. wrote:
|
|
I had a similar experience today, trying to open an owl file from the Desktop (Ubuntu 14.04, 8GB RAM) I waited for a few minutes until a very small ontology was opened. See dump below. In fairness, it turns out I had a subfolder with several hundred OWL files. The generated xml catalog had 8884 lines. Can the catalogue be generated in a separate thread, especially if the OWL file does not have any imports? |
Observation: The user tries tries to open a file, and Protege seems to freeze, although it is working hard.
What happens: Protege tries to find local imports in the subfolders of where the ontology file is located, and if they are deep, or have many files, it can take a very long time.
Possible culprit: the catalog implementation might be too greedy. At least it should not go into the hidden folders.
Possible solution: search only in the top level (or x levels), and then pop a dialog to the user asking if the search should be continued, or go to the Web to get the imports. The import search should not even be started if the ontology has no imports.
Report from user:
This turned out to be a peculiar bug loading files (File Open) where the user interface never comes back though there's apparently enough Protege running to send a "piss off" to the window manager when I try to kill the window.
I can get around the bug by copying the file I want to open by copying its contents to another file, starting protege, File SaveAs (an empty ontology) to the file I want to load, copy the other file back over the truncated file, accept Protege's offer to reload. As streamlined as this seems to be, I have the nagging suspicion that my life would be still better if I could nail down this bug.
I used jdb to examine the diff between 4.3 and 5.0 before and after loading (or attempting to) a vapid asdf.omn. but having source for neither, my observations are probably irrelevant:
4.3 kills a sleeping Keep-Alive-Timer thread and
creates a sleeping Image Animator 3 thread.
5.0 kills a waiting Image Fetcher 3 thread and
changes AWT-EventQueue-0 from waiting to running (walking?)
Top showed a couple threads chewing up 100% of their respective CPUs so I gdb'd the child thread. It was busy walking through a hillariously deep directory structure that appears to be bastard child
of Wine and Virtual Box. I saw it xstat'ing the hell out of a directory tree under:
/home/eric/.wine/dosdevices/z:/sys/dev/char/10:237/subsystem/tun/subsystem/network_latency/subsystem/rfkill/subsystem/network_throughput/subsystem/hpet/subsystem/vboxdrv/subsystem/vboxnetctl/subsystem/loop-control/subsystem/vboxnetctl/subsystem/network_throughput/subsystem/hpet/subsystem/rfkill/subsystem/loop-control/subsystem/vboxnetctl/subsystem/rfkill/subsystem/
noted by stopping and seeing xstats of:
tun/subsystem/ecryptfs/subsystem/vga_arbiter/subsystem/psaux/power/async
tun/subsystem/device-mapper/subsystem/device-mapper/subsystem/loop-control/dev
network_throughput/subsystem/psaux/subsystem/tun/subsystem/cpu_dma_latency/power/autosuspend_delay_ms
The text was updated successfully, but these errors were encountered: