Announcement

Collapse
No announcement yet.

kwrite on big files -- 14.04 was fine, 16.04 sucks

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    I am at my remote office, where I have a different kubuntu 14.04 desktop (kwrite works OK on big files) and the laptop that I used for the test in post #10.

    I realized I had a laptop drive on which 16.04 was installed. I popped it into the laptop and updated it (sudo apt-get update, sudo apt-get dist-update).

    Kwrite says the editor component version is kate part version 5.18.0.

    Using 16.04 on the exact same (14.04) laptop I used in the tests described in post #10, I had almost exactly the same results as reported for the 16.04 desktop -- kwrite sucks. Maybe it took 10 seconds, rather than 8, for the cursor to reappear after pressing the up arrow for 5 seconds.

    Caveat: after pressing the up arrow for 5 seconds, the cursor makes an appearance after about 2 seconds, but keep watching, it finally comes to rest up higher after 8-10 seconds.

    So now I have ready for my 8 gb laptop, two system hard drives, one with 14.04, the other with 16.04. It is easy to swap them.

    > I would suggest that you delete /home/$USER/.config/kwriterc and /home/$USER/.local/share/kwrite and then reinstall kwrite: sudo apt-get update && sudo apt-get install --reinstall kwrite and see if things improve.

    I did as you suggested on the laptop using the 16.04 drive, and found no improvement -- kwrite still sucks.

    > My test was to download the file above, open in with kwrite, use the scroll bar to move to the bottom of the file, hit the Page Up key several time, done.

    > Locked kwrite every time.

    I tried it, and I did not have a problem using the scroll bar to go to the bottom. For my tests, I go to the bottom using Ctrl-End (as is my habit).

    > I am at my remote office, where I have a different kubuntu 14.04 desktop (kwrite works OK on big files) and the laptop that I used for the test in post #10.

    jlittle says 16.10 works OK, as a test, I will use the 8 gb desktop and install 16.10 on a different hard drive (I will be able to go back to my working 14.04 system).

    Comment


      #17
      I changed my mind, I installed 16.10 on the laptop, I did a clean install from the ISO on a previously wiped hard drive. For me, kwrite sucks in 16.10 -- I get exactly the symptoms I have described, to wit:

      > I went to the bottom of the file, and from the bottom I selected up to and including the line "The consequences:". I copied the selected text. I used PgUp several times until I came to the heading "The GNU Manifesto". Above that heading, I hit Paste (Ctrl-V), and counted "one thousand one, one thousand two, one thousand three, ..." The inserted text appeared between one thousand five and one thousand six. I hit Ctrl-Z. I held down the up arrow key, and kept holding it down while I counted ""one thousand one, one thousand two, one thousand three, one thousand four, one thousand five" then I released the up arrow key, and started counting again. The cursor did not come back after I counted up to one thousand eight.

      In 16.10, kwrite says the editor component version is kate part version 5.26.0.

      Note that if I pop the 14.04 hard drive into this laptop, kwrite is fine.

      Comment


        #18
        Looking at this again, I wonder how fast your computer is...

        On mine, which was the fastest consumer grade Sky Lake when it was new (albeit multipler locked) just over a year ago, if I do your test of scrolling to the end and holding down the up arrow key, one (virtual) CPU goes straight to 100%, and if I max out the keyboard repeat rate in system settings to 50 Hz kwrite and kate become noticeably stuttery; it's avoiding updating the screen because it doesn't have time.

        Using other GUI editors I have installed, gvim, geany, and emacs 24, with the same exercise, in the system monitor (ksysguard) their traces on the system load graph are lost in the clutter at the bottom, registering 1 to 3 % in the process table. I conclude that kate is now a CPU hog, bad on normal sized files and terrible on largish ones. It tries to reduce screen updating to cope but fails on your computer. gvim and geany scroll the text smoothly.

        If you're really attached to kate or kwrite, I can only suggest a visit to https://bugs.kde.org/, the KDE bug tracker. Bug 378330 is recent and looks related to your problem; perhaps you'd like to comment on it.

        If not, well, I'm a big fan of Vim, having started with vi too many years, nay decades, ago. geany has an outspoken fan here. I've worked with a few GB log files with vim, ok while RAM is not full. (Syntax colouring log files, even very simply, can be a huge help.)
        Regards, John Little

        Comment


          #19
          jlittle, you gave such a glowing recommendation for geany that I just had to download it (and all of the other 60 pkgs in the repository related to it) and give it a try on some Qt code I have.
          "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
          – John F. Kennedy, February 26, 1962.

          Comment


            #20
            Originally posted by GreyGeek View Post
            jlittle, you gave such a glowing recommendation for geany that I just had to download it (and all of the other 60 pkgs in the repository related to it) and give it a try on some Qt code I have.
            I would give geany a glowing recommendation; it's my go-to when I'm not using KDE

            The thing I miss with geany is I've grown quite fond of kate's search and replace at the bottom of the window.
            we see things not as they are, but as we are.
            -- anais nin

            Comment


              #21
              Originally posted by wizard10000 View Post
              ... I've grown quite fond of kate's search and replace at the bottom of the window.
              Open a folder with thousands of text files in it and do a search for a word or term and Kate finishes *VERY* quickly. In one with 1,700+ files it took a fraction of a second. In one with 5,000 files about 2-3 seconds. Here's an example of " hide " (as in the decline):

              Click image for larger version

Name:	Screenshot_20170407_122044.jpg
Views:	1
Size:	80.5 KB
ID:	643495

              I've had as many as several hundred selections in the bottom panel and as I clicked on each one the file opened in the top panel and display the search word, highlighted in yellow.
              "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
              – John F. Kennedy, February 26, 1962.

              Comment


                #22
                I posted a big on bugs.kde.org:

                https://bugs.kde.org/show_bug.cgi?id=378579

                Does it matter how fast or slow my computer is?

                Quoting from the bug quote:

                > Right now, I have two hard drives for my Lenovo Thinkpad T500 laptop with 8 GB memory, one hard drive with kubuntu 14.04 (kate version 3), and another hard drive with kubuntu 16.04 (kate version 5/15). I can shut the laptop down and swap hard drives. You can say my laptop is too slow, but kate version 3 works perfectly OK on my laptop -- no complaints. But on the same laptop, kate version 5/15 sucks.

                Comment


                  #23
                  BTW, yes, bug 378330 seems to be related, but that is only about the paste delay. If my only problem was the paste delay, I would live with it and I would never have complained. For me, the much bigger aggravation is the arrow keys do not work well in 16.04 and 16.10, kate version 5/15 (kate says version 15, kwrite says kate version 5).

                  Comment


                    #24
                    Originally posted by likes2skate View Post
                    Does it matter how fast or slow my computer is?
                    The reason I asked was that if some action goes 100% on a fast machine, a slower won't cope. I suspect there's some nastily inefficient code, which has passed testing because the tests were run on fast machines. I compared with other editors to show that this CPU usage is unnecessary; decades old processors should be fine. IMO it's clearly something crazy wrong with kate, and it's good that you're willing to help by raising a bug.
                    Regards, John Little

                    Comment


                      #25
                      For use on big files, it seems the minimum hardware requirements for the kate editor exceed the minimum hardware requirements for kubuntu.

                      I think the bottom line that is for big files, kate needs 4 cores, 2 cores are not enough.

                      https://bugs.kde.org/show_bug.cgi?id=378579#c11

                      Comment


                        #26
                        Looks like Rick Graves discovered that he doesn't live in an "ideal world". Corollary: developers don't have access to all of the many hardware configurations that their software runs on, and, they are not psychic.


                        Sent from my iPhone using Tapatalk
                        "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
                        – John F. Kennedy, February 26, 1962.

                        Comment

                        Working...
                        X