PE very slow with large files

[sarkipo]

PE is getting extremely slow with some files. It's perhaps related to the total number of events on all tiers, not just on the length or just the number of tiers. A couple of problematic ones are in the attachment. One is just long (ca 50 min), the other is ca 15 min but has two speakers, and we typically have ca 25 tiers pro speaker.

bigfiles.zip

Typical symptoms: several seconds (e.g. from 7 to 15 seconds) for every single click to have its effect. Sometimes, it is suddenly working fine after a while. Sometimes, it does not.

Noticed earlier that such slowdown happens when a media file is linked but not found. Thought it might be related to media framework, tried to switch to BAS. After this, one file got working ok but the other didn't -- so don't know if it's really related.

[Herrner]

Did you check the system load (processor/ram) when this happens? I can't really reproduce this on a M1-Mac. It ist not blazingly fast, but far from >1s.

[berndmoos]

I cannot really reproduce it either. Yes, the PE GUI becomes less reactive with larger files (where "large" means that #tiers x #intervals is large). With the example files, it is not fast (Windows 11), but certainly not >1s. If and when you see this again, try leaving the editor open, but open a smaller file. If the problem persists, that might be a hint that the reason is something other than the GUI component struggling with many table cells. If it does not persist, I'd say your computer is not up to it :-/ In that case, you can alway split transcripts to a size that can be handled, and reassamble (merge, glue) them as needed.

[sarkipo]

@Herrner: When this happens, the problematic PE process takes all of one of the cores (ca 13%, eight cores) and up to 350-400 Mb memory -- it does not eat gigabytes. Along with the CPU usage, some GPU usage is also reported.

@berndmoos: I've opened a couple of files, the two first working ok, the third one (KES_ChND_Childhood) became slow -- ca 2-3 seconds per click. I also opened a fourth file. Now all three except Childhood run fast, Childhood is as slow as before.

I wouldn't expect this particular computer to be too weak: Processor 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz 2.30 GHz Installed RAM 32.0 GB (31.7 GB usable) Edition Windows 10 Pro Version 21H2 and it still has >150 Gb on the hard drive.

[sarkipo]

P.S. When the click is finally processed, CPU usage drops to 0, then rises again after another click. The other programs running in parallel seem not to be affected.

[sarkipo]

@Herrner @berndmoos Shall I also send you the sound file to try and reproduce the thing?

[berndmoos]

@Herrner @berndmoos Shall I also send you the sound file to try and reproduce the thing?

Yes, please :-)

[sarkipo]

Here it is: https://we.tl/t-WVpxrB4BX7

BTW, there is a borderline state when clicking within the screen works fine but scrolling doesn't

[berndmoos]

Sorry, I still cannot reproduce this. I am testing with "Childhood" on Windows with the WAV file and the JDS player. I can click anywhere and get an almost immediate reaction (maybe <0.1s delay). I can edit text in events with no delay. I can play all selected audio segments with no problems.

I notice that some characters are not displayed in tiers of category "mp". This tier is formatted with font "AGA Arabesque". This font is installed on my system, so I am wondering whether you are using a special version of that font (so that all characters are displayed)? If yes, that might be a possible cause.

Otherwise: have you checked that the same phenomenon also occurs on other computers with the same files? Are your WAV files stored locally or on some network drive or in a cloud folder?

[Herrner]

Can't reproduce either, not on M1 Mac and not on Linux. Response times are not "snappy", but not "laggy" either.

[sarkipo]

Can't reproduce either sigh sigh I see, unfortunately I don't have a recipe to reprduce it... I must say the problem does not appear very regularly on my PC either, sometimes it's just fine, and sometimes the lag is smaller. But once it is there, the delay is roughly the same with each click within a session until I close PE (or until the problem is suddenly gone), e.g. always 2 sec, or always 7 sec, or always 15 sec, etc. Right now it was five times in a row with 8s-12s per click.

I now removed the link to the wav file and it's still lagging.

@berndmoos: I don't know where the "AGA Arabesque" comes from ;-) We've got "Charis SIL" in all tiers. "AGA Arabesque" looks like being first font name alphabetically, but I don't have such a font. I also removed that weird character, no effect. Saved without formatting and reopened, also no effect.

Are your WAV files stored locally or on some network drive or in a cloud folder? Stored locally, same happens in different folders on the hard drive.

Otherwise: have you checked that the same phenomenon also occurs on other computers with the same files? I've checked, and it's not the same.-( Sometimes, but not reproduced reliably...

[berndmoos]

There is a hint that (newer versions of) Charis SIL are buggy (#124). I do not seem to have the font installed on my computer, you do. It is a weak hypothesis, but at least it is one: try to reformat the transcriptions and/or uninstall the font and see if the problem persists.

[sarkipo]

Saved without formatting, all is now in Times New Roman, same thing. (Also installed Charis SIL 6.200, same thing).

[berndmoos]

I don't have much to go on here. Since it seems to occur on an irregular basis, maybe some specific action carried out before causes the slowness. Next time the problem occurs, can you get us the log file?

[berndmoos]

BTW: Have you turned on automatic backups? If so, at what intervals? If it is a very short interval, maybe make it longer?

[sarkipo]

Autosave is set at 60 min, so unlikely to be the reason.

Next time the problem occurs, can you get us the log file? Easy, I've got it right now :-) How/where do I get the log file?

[berndmoos]

How/where do I get the log file?

Help > About > Copy debug...

[sarkipo]

pe-log-20230224-01.txt

[sarkipo]

I thought it might be related to graphic rendering, so I unplugged the docking station with external monitors. (Without closing PE.) The result was slightly unexpected: the peak processor load on actions in PE dropped to ca. 1/3 of a core (4-5%) but the time grew up to over 20 sec... I didn't last long and plugged the thing back in...

[sarkipo]

Again thinking of the graphic connection, I also have a weird screen overflow behaviour which is, in contrast, regular, but not so annoying. Will write a separate issue, don't know if it's connected.

[berndmoos]

pe-log-20230224-01.txt

There is nothing special in the log file. It looks largely identical to the one from my computer, the main difference being that you are on Windows 10 wheras I am on Windows 11. Downwards compatability was never a problem on Windows before, though. One more question to the patient: Could you say that this problem started occuring at some point in the not-too-distant past? I.e.: Was there a time when you worked with files of that type, and the slowness did not occur? If so, I would suspect that something in JDK 17 (which I introduced with #339 ) is not working with Windows 10, but 11.

[sarkipo]

Could you say that this problem started occuring at some point in the not-too-distant past? I.e.: Was there a time when you worked with files of that type, and the slowness did not occur?

I'm afraid I don't remember... I have a vague impression that this is more ancient, but I never had to work a lot with the Nganasan corpus where all the biggest files concentrate, or I would occasionally grab and convert some to Praat Textgrids.

There is nothing special in the log file.

Is there a (simple) way to produce a more detailed log? i.e. to see which function takes so long?

[berndmoos]

Is there a (simple) way to produce a more detailed log? i.e. to see which function takes so long?

No, and I don't think that it is a PE function that is actually eating the time. Rather, it is some operation which requires a lot of memory or CPU and thus slows down the processes that follow it. Sadly (or not), the log file is completely inconspicious in that respect.

So, to summarize the current state of cluelessness (please correct if necessary):

1. Under some circumstances, operations in the PE slow down so much that the editor becomes unusable
2. This only happens with files with above a certain size as defined by number of tiers x number of time intervals
3. The problem is reproducable on @sarkipo's Windows 10 machine, and it may have been seen on other machines, @berndmoos and @Herrner, however, have not been able so far to reproduce it on a Windows 11 and MAC OS (M1) and Linux machine
4. On the machine where it can be reliably reproduced, there is also an unexplained and otherwise unknown phenomenon in the graphic display of the partitur (#373 )
5. Auto save and special fonts can probably be excluded as causes of the problem, there is nothing in the log file that would explain the phenomenon

If and when I find the time to really simulate working with one of the examples, I can try once more to reproduce it on my machine. Otherwise, I am setting this aside as long as I don't get similar complaints from other users.

[marbryk]

I have the same problems with PE getting slow, sometimes, with some big files. Today, I have 20+ seconds delays with the file which worked well yesterday, and 5+ seconds on another one.

[sarkipo]

MVL_090807_Hungabtadja_flks.zip

Here's our today's hero (MVL_090807_Hungabtadja_flks). On @marbryk's laptop, it had 20+ sec between clicks. I've tried it on my laptop as well; at first, it just took 5 minutes to load and then worked all right for some short time, even allowing scrolling without substantial delay. Then I closed it and reopened to measure the load time; it was 1 min until "Calculating widths..." finished + 2 min 15" until the Partitur was displayed + 2 min until the CPU load dropped. After a few clicks OK it went into slow mode again (1 min 40'' per click). Also some menu commands got slow; e.g. Hide tiers (40 sec), detach sound (1 min), change scale constant, show tiers.

[berndmoos]

Thanks for the example. It is truly of monumental size: 43 tiers, 5000 timeline items, file size 2.6MB. Naturally, it takes longer for files of this size to carry out operations for the entire transcript. Opening the file or (for instance) reformatting the partitur takes longer than 10 seconds on my (Windows 11) machine. However, I have had the file open for several hours now. I have added tiers, split and merged events, carried out an auto annotation and added manual annotations at random places in the transcripts. The interface still reacts almost immediately, i.e. within a fraction of a second.

I have two hypotheses:

(1) The Charis SIL font is causing the slowness. I do not have it installed on my machine, but most tiers would be formatted in that font if I had. So we now need a witness who is seeing this problem and who hasn't Charis SIL installed. Can you uninstall it and see if the problem persists? (2) It is a Windows 10 problem only. EXMARaLDA has long been running smoothly on Windows 10, but the newer previews are made with Windows 11 and a newer Java Runtime Environment. I think it is unlikely that the Windows version is the cause, but cannot verify it, since I cannot afford a fifth computer. If there is a witness who sees this on Windows 11, he or she shall come forth and speak out

And I have three questions: (1) Are you seeing these problems now, but have worked with such large files in the past without the problems? (2) Is this kind of transcript built-up manually in the Partitur-Editor or are you building the main parts of it outside (e.g. with scripts, another tool)? (3) Is there a fundamental reason that keeps you from splitting transcripts when they become too large? In every other case with slowness of the interface, this was the solution that worked.

[sarkipo]

Moin moin, here are monday's news on the issue.

(H1) While there might be something related to the fonts, it is not straightforward. I did have Charis SIL (v6.200) installed, and I changed it to Times New Roman everywhere in the exb, removed Charis SIL from the system and rebooted, with no effect. On the other hand, when I installed the 2019 release of EXMA, I also had Agency FB instead of Charis SIL, and Charis SIL was not shown in the list of available fonts (though it was not yet removed from the system. @marbryk, on the contrary, did not have Charis SIL and installed it, with no effect either.

(H2) I'll keep an eye on people with Win 11. So far we've got colleagues with Win 10 who do NOT (yet?) have the issue. (And one on Linux for whom PE just stopped to run at all, but that's another story).

Questions

(1) Are you seeing these problems now, but have worked with such large files in the past without the problems?

As for me, I usually didn't work with these very large files. @marbryk did have such problems before.

(Q2) These are files created with an import stylesheet from *.flextext files, coming from SIL FLEx.

(Q3) Perhaps not, except that it will require either splitting records in coma or changing the approach for filename structure, and eventually some additional hassle with time alignment. I'd say, nothing fundamental, just annoying.

Observations

(O1) Obviously, the old 2019 release does not have the issue. (The Charis SIL font is not available at all, but this does not seem to affect the speed by itself). The file also loads faster on 2019 version. (I might try to install a few intermediate versions to find the one where it appeared. New Java?)

(O2) Sometimes, especially if some tiers are hidden and the remaining ones fit on the screen, there is no problem. But then, after some operation (e.g. window resizing, or showing all tiers, or just some edit) it is back again, and then it remains.

[sarkipo]

Okay, and the issue is confirmed on a Win 11 system (with this last big Hungabtadja file). (And the project leader is against splitting files)

[sarkipo]

Another colleague on Win 10 did not have the issue

Edition    Windows 10 Education Version    21H2 Betriebssystembuild    19044.2728 Leistung    Windows Feature Experience Pack 120.2212.4190.0 Prozessor    Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz   1.90 GHz Installierter RAM    8,00 GB (7,88 GB verwendbar) Systemtyp    64-Bit-Betriebssystem, x64-basierter Prozessor

It turned out she had an old version of EXMA (20210206). I installed that one, too; the Hungabtadjaa was slow but, say, 5 sec instead of 40 or 100.

[berndmoos]

And the project leader is against splitting files

Fair enough. What is she for then?

[sarkipo]

Ideally, for finding & fixing the thing... Otherwise, we'll have to see what options are worse for what reasons

[sarkipo]

One more reason why we'd like to avoid splitting files is that we'll have to adjust the statistics somehow (counts of texts, text duration / text length in sentences/words, etc.) Again, not impossible, but annoying

[berndmoos]

Note to self: The partitur GUI component is known to be in trouble when there are events to display which stretch over a lot of time intervals. I do not think this is the case here, but once we see the problem in action, we could check.

[berndmoos]

We looked at this in a meeting of international experts on editor slowness in EXMARaLDA tools. The phenomenon can be reliably reproduced on two Windows 10 machines. Transcription size may not even be the decisive parameter. The problem continues to be not-reproducible on other machines. It seems to always occur together with #373. Hiding tiers with events over longer interval spans did not make a difference. Deleting such tiers did, but probably only because it resulted in the partitur fitting on the screen (i.e. no vertical scrollbar needed). On the same machine, the problem could not be reproduced with the latest official version of the PE, dating from 2019 and using a 32-bit Java 8 SDK from Oracle, whereas the current preview is 64-bit/Java 17/OpenJDK. So the new best guess is that soemthing in OpenJDK 17 does not go well with some specific thing on those two machines. The plan is now to build a distribution in which JDKs can be switched (#392) and see if the problem can be reproduced on this machine with either JDK 11, JDK 14 or JDK 20. The desired outcome would be that it goes away with JDK 20.

[berndmoos]

Batch file is now on https://exmaralda.org/en/preview-version/ via #392

[sarkipo]

So I finally did some testing on my machine (yet to test on @marbryk's), with "Giant" (also with smaller files to compare)

• JDK 20, same as current preview with JDK 17: very slow to open, extremely long response time afterwards (tens of seconds)

• JDK14, JDK 11: slow to open, long response time afterwards (like 10 times faster than JDK 17/20, not impossible to work, but still ca 4 seconds if scrolling/jumping through timeline is needed)

• JDK8,9,10: PE does not launch with errors like the following: Error: LinkageError occurred while loading main class org.exmaralda.partitureditor.partiture.PartiturEditor java.lang.UnsupportedClassVersionError: org/exmaralda/partitureditor/partiture/PartiturEditor has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 54.0

2019 release, Java 8: blazingly fast, no delays whatsoever

[berndmoos]

The current batch version will run with Java 11+. I can probably rebuild to make it run with Java 8+. Will do soon ;-)

[sarkipo]

BTW, am I right that the only thing which is used from the JDK is the java.exe file itself? (and all the rest is taken from the exmaralda distribution)?

[sarkipo]

Meanwhile, results from @marbryk and the "Giant" The general pattern is the same: JDK 17/20 ~25-50 seconds, JDK 11/14 is faster (~8 seconds) but still impossible to work, old release with Java 8 works as a breeze

Some more details (delays in seconds, roughly) just for the protocol: EXMA/Java version: open file -- scroll timeline -- dblclick annotation new batch/11: 10 -- 5 -- 9 new batch/14: 8 -- 4 -- 7 new batch/20: 43 -- 26 -- 49 20230512/17: 43 -- 0 -- 50 20191008/8: 6 -- 0 -- 0

[berndmoos]

BTW, am I right that the only thing which is used from the JDK is the java.exe file itself? (and all the rest is taken from the exmaralda distribution)?

Not sure I understand the question. The Windows distributions have the JDK binaries under runtimeand the Java (bytecode) libs under app. In the batch, the java.exe will need all the DLLs which make up the JDK.

The general pattern is the same: JDK 17/20 ~25-50 seconds, JDK 11/14 is faster (~8 seconds)

Extrapolating that: Java 1.1 should be very fast ;-)

[sarkipo]

The general pattern is the same: JDK 17/20 ~25-50 seconds, JDK 11/14 is faster (~8 seconds)

Extrapolating that: Java 1.1 should be very fast ;-)

Indeed! :-)

[sarkipo]

Not sure I understand the question. The Windows distributions have the JDK binaries under runtimeand the Java (bytecode) libs under app. In the batch, the java.exe will need all the DLLs which make up the JDK.

I just wanted to make sure that I only need to change one line in the batch, namely the JAVA_CMD one: set JAVA_CMD="C:\DSTB\jdk-11.0.2\bin\java.exe"

Does this java.exe know that it should look into its own folder if it needs anything? Because there seems to be no command to specify the JDK folder as such.

[berndmoos]

Does this java.exe know that it should look into its own folder if it needs anything?

Yes, it does.

[berndmoos]

I'm afraid I found there is no way of going back to JDK 8 -- some third party libraries (e.g. ELAN and BAS Audio player) would also have to be rebuilt, and some packages (e.g. using java.awt.desktop) are needed that were introduced only in Java 11. So JDK 11 is the closest we can get to the last official version, but I understand it makes no real difference to JDK 17

[sarkipo]

I'm afraid I found there is no way of going back to JDK 8

Sad, but that's what I expected... We just tried updating @marbryk 's system to Windows 11, it didn't help, unfortunately