-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
64-bit Tines As Slow As 32-bit Hnb? #20
Comments
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 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
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. But for my largest hnb file for example, as you asked: |
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..?
The text was updated successfully, but these errors were encountered: