Open grokk opened 6 years ago
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.
'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
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. :/
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.
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..?