Okay, I already opened "huc6-u+0000-u+ffff.tbi" from the HUC Braille Tables (1.94 MB, 65,568 lines) with the portable (7z) versions of Notepad++ 7.7 on Win7x64 with NVDA 2018.1. The 32-Bit version loaded the "little" tbi file (= plain/normal text file) immediately and the 64-Bit version required up to 11 seconds on an Intel Core i7 960 (more than 9 years old, but still fast enough) with 6 GB RAM. Okay, both portable Notepad++ versions were extracted on and run from a HDD, not from a SSD, on which Win7 is running. But after the tbi file was fully loaded in Notepad++ 64-Bit, searching for "266f" worked as expected. And it's the same with the navigation within this tbi file.
i tested with nvda 2017.2 which is the best version for me on windows xp and notepad++ 7.7 32bit.
i tested one book which is 4.19 mb in html format and even i converted it to text and cant reproduce the mentioned issue in html and text format of my book!
notepad++ opened for me these files very fast and nvda did not freeze.
but since my book is very large, (it contained 1307 when i opened it in libreoffice,) navigation in html file especially was a little slower than simple files for me.
When expanding to character, NVDA sends the SCI_POSITIONAFTER message to the control, passing -1 in the case offset is 0. However, in the X64 version of Notepad++, the result of that call is the length of the document, whereas in the X86 version, it returns 0 as expected.
In the case the length of the document is returned, NVDA ends up in a while loop. This code really has to be revisited.