64-bit Tines As Slow As 32-bit Hnb?

[grokk]

I finally got around to compiling tines on Debian Buster, after years of putting it off. Large files in hnb are simply just achingly slow to interact with. However, I see little improvement with using tines in the same large .hnb/.xml files. Is there anything I can do about that -- aside form splitting up the files..?

[larrykollar]

I haven't put any work into improving performance. How large of a file are we talking about (# of nodes as well as file size)? What vintage hardware? The default .tines file is about 59K and 622 nodes; my personal one is 97K and 1432 nodes. I regularly work with files in that size range on hardware ranging from 3-10 years old, and haven't noticed it being terribly slow.

Can you do this for me?

ls -l bigfile.hnb
xmllint —format bigfile.hnb | grep -c '<node'

If you have any experience with profiling, maybe we can find a performance bottleneck and work on it.

On the off-chance that it's a matter of the menus being slow to respond, find the escdelay setting in your .tinesrc and setting it to a lower value, like this:

escdelay 100

Tines pauses when receiving a single ESC to make sure there's not an ANSI sequence following. You might want to experiment with even smaller values (the units are milliseconds) unless you're using a terminal with a 1200 bps serial connection. If you hit an arrow key and get the menus, you know you've set it too low.

[grokk]

'I haven't put any work into improving performance.'

Oh. I kinda assumed making the executable 64-bit almost as a matter-of-course involved the introduction of efficient paging of large files being edited... oh well. But the problem is the file size. Nothing else.
:/

...and the big ones are HUGE files, indeed: between 5-25 MB, some.

NB: I use a LOT of 'formatting'/presentation -- which greatly pads these files... but frankly: I want to keep things that way for now.
And I'd rather leave it at that, here.
:)

But for my largest hnb file for example, as you asked:
From ls -l: ... 25651377 ... foo.xml (but hnb format)
From xmllint: 550498 nodes..!!??
:D

[grokk]

Right now, FYI (while anticipating my moving from using the hnb/xml to opml format; and while use tines in place of hnb): I am splitting my files up (inconvenient, less productive and more work); AND I am also systematically stripping out certain of the 'padding' I use (to make these files more AFAIC readable) inside each file.

It's a stop-gap.
:/

[grokk]

It is also my (unscientific, unproven) perception that tines might just be a tad slower with large files, than hnb was/is (in Debian). But I could be hallucinating that.