Move method in textInfo objects is slow when moving by many characters

[nvdaes]

Steps to reproduce:

1. Install the placeMarkers add-on.
2. Open a large document such as the NVDA's user guide.
3. Press control+end.
4. Place a bookmark for example pressing NVDA+control+shift+k.
5. Press control+home, then NVDA+k; or NVDA+alt+k, then Enter, to move to the bookmark.

   Actual behavior:

   In alpha snapshots, NVDA is extremely slow, and this doesn't happen in NVDA 2018.4.

   Expected behavior:

   NVDA should find the corresponding character (using the move method in textInfo objects) quickly, similar to NVDA 2018.4 or other versions.

   System configuration

   NVDA installed/portable/running from source:

   Any

   NVDA version:

   alpha-16458,5e710dac

   Windows version:

   7 or 10

   Name and version of other software in use when reproducing the issue:

   Chrome or Firefox.

   Other information about your system:

Other questions

Does the issue still occur after restarting your PC?

Yes

Have you tried any other versions of NVDA?

Yes, NVDA 2018.4, and this doesn't hapen

[dan1982code]

I confirm this, and also note the same behaviour in Internet Explorer (so it does not seem specific to one browser).

[Adriani90]

cc: @leonardder, @michaelDCurran

[josephsl]

Actual CC: @LeonardDer just in case the text infos change may have caused this performance problem.

From: Adriani90 notifications@github.com Sent: Wednesday, December 19, 2018 7:37 AM To: nvaccess/nvda nvda@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [nvaccess/nvda] Move method in textInfo objects is slow in alpha snapshots (#9093)

cc: @leonnarder, @michaelDCurran https://github.com/michaelDCurran

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/9093#issuecomment-448638424 , or mute the thread https://github.com/notifications/unsubscribe-auth/AHgLkNGus5MU_-gCVpg9ezxM6DUk8uVhks5u6l0jgaJpZM4ZaJD4 .

[LeonarddeR]

I also noticed that firing up the python console and using tab to autocomplete on an NVDAObject seems to freeze.

[LeonarddeR]

@nvdaes: Could you please come up with a native NVDA way to reproduce this, i.e. without the placemarkers add-on? Is it slow in case of moving with a specific unit, for example?

[nvdaes]

The unit used for movement is UNIT_CHARACTER, and I don't know a native command available in NVDA to reproduce this. We can create a test script in NVDA and try to reproduce in a large document.

[dan1982code]

I also can't see a way to reproduce this in native NVDA. I trawled a lot of code just now for virtual buffers but don't see a way to force a character jump. For example, opening the user's guide and using any single-letter navigation is still fast, no matter the distance between occurrences.

[LeonarddeR]

You can do this by opening the user guide, firing up a python console and execute the collowing: nav.treeInterceptor.makeTextInfo("caret").move("character", 100000)

This is definitely caused by #8953. I have code to improve this, but it will never be as fast as before.

Note that the way place markers works isn't very accurate. I'm not going to debate the saving of the character positions here.

1. When placing a bookmark, the character count is based on the length of the text from the start of the document up to the caret. However, it is just sufficient to create a textInfo for the caret only and than use caretInfo._startOffset. This only works for offset based text Infos though, but virtual buffers are offset based
2. If the saved character counts are offsets, you can easily create a textInfo that is positioned at the saved offsets by passing a textInfos.Offsets object to the makeTextInfo method of the tree interceptor.

Note that #8953 changes things in such a way that some characters (i.e. emoji) occupy two offsets.

[LeonarddeR]

I have code to improve this.

Actually, the method I wanted to try is using uniscribe to calculate offsets, but this is around one second slower than the current implementation. Previously, it took like 0.2 seconds to move 100000 characters, whereas the current Alpha snapshots need more than 7 seconds to move such a huge amount of characters.

@jcsteh and @michaeldcurran: It would be good to know your thoughts about this. Honestly, my opinion is that place marker's implementation suffers from several inadequacies and is based on wrong assumptions.

[nvdaes]

OK, I thought that startOffset was not intended to be used in add-ons due to the symbol. Let's wait for other opinions. I don't know if issue #88 could be reopened or not for previous patent concerns.

[LeonarddeR]

You're correct. It is better to use bookmark.

[nvdaes]

Thanks, I will investigate it. If I have questions, I will ask on mailing lists to preserve the topic on this issue related just to NVDA.

[nvdaes]

Using bookmark there is no problem with performance in placeMarkers add-on. Let me say you are really amazing. Anyway, this issue could make sense for other implementations, but for placeMarkers is not needed. Thanks

[Adriani90]

Is this still occuring in NVDA 2019.3 Beta 2?

[nvdaes]

Is this still occuring in NVDA 2019.3 Beta 2?

Yes, tested in NVDA 2019.3beta2.

[Adriani90]

@nvdaes could give a short update if this is still the case in NVDA 2022.4 and Firefox 109 or Chrome 110?

[nvdaes]

I've tested with the last source code of NVDA at this moment andFirefox Nightly, and the issue persists. If you need that I test it specifically with NVDA 2022.4 and other browsers let me know. Anyway, this is not affecting placeMarkers add-ons since we use bookmarks now, and this is absolutely efficient, in contrast with the move method when text is too long.

[Adriani90]

@nvdaes in the NVDA 2023.3 release cycles there were some PRs tackling performance in general. Could you please test with the last NVDA alpha and report if this issue is still occuring?

[Adriani90]

Testing with NvDA 2024.2 Beta, NVDA still takes more than 7 seconds to move beyond such an amount of characters:

IO - speech.speech.speak (01:25:53.461) - MainThread (21964):
Speaking ['NVDA-Python-Konsole']
DEBUG - NVDAObjects.NVDAObject._get_placeholder (01:25:53.461) - MainThread (21964):
Potential unimplemented child class: <NVDAObjects.Dynamic_NvdaPythonConsoleUIOutputClearIAccessibleEditWindowNVDAObject object at 0x060C56B0>
IO - speech.speech.speak (01:25:53.461) - MainThread (21964):
Speaking ['>>>', 'Eingabefeld', 'Leer']
IO - inputCore.InputManager.executeGesture (01:25:55.522) - winInputHook (12172):
Input: kb(laptop):control+v
IO - inputCore.InputManager.executeGesture (01:25:56.812) - winInputHook (12172):
Input: kb(laptop):enter
DEBUG - watchdog._waitUntilNormalCoreAliveTimeout (01:25:57.321) - watchdog (10144):
Potential freeze, waiting up to 10 seconds.
IO - inputCore.InputManager.executeGesture (01:25:58.134) - winInputHook (12172):
Input: kb(laptop):downArrow
IO - inputCore.InputManager.executeGesture (01:26:01.602) - winInputHook (12172):
Input: kb(laptop):downArrow
DEBUG - editableText.EditableText._hasCaretMoved (01:26:03.791) - MainThread (21964):
Caret move detected using event. Elapsed 0 sec, retries 0
IO - speech.speech.speak (01:26:03.791) - MainThread (21964):
Speaking ['Leer']
IO - speech.speech.speak (01:26:03.791) - MainThread (21964):
Speaking ['100000']
IO - speech.speech.speak (01:26:03.791) - MainThread (21964):
Speaking ['>>>']
DEBUG - watchdog._waitUntilNormalCoreAliveTimeout (01:26:03.827) - watchdog (10144):
Recovered from potential freeze after 7.0061411000206135 seconds.

This had also a negative impact on text style navigation, one of the reason why it had to be disabled in different use cases in MS Office.

cc: @mltony

[mltony]

This could indeed be contributing to styleNav performance issue in MSWord and Outlook. StyleNav uses TextInfo.moveToCodepointOffset(), which internally calls TextInfo.move(character, n).