I'm having myriad problems with gedit and large text files. OK 81MB isn't really that large, it should be able to handle that without this much difficulty.
First, it takes a long time to open, more than a minute, and this is on an SSD. Next, it's doing some processing for a really long time after it loads the document, about 5-6 minutes, while the process consumes 100% CPU and the fans start running on high like I'm blowing my hair dry rather than reading a document.
But the actual problem is, at some point I click out of gedit, then back into gedit, and somehow the white background becomes black. So it's a sea of black text on a black background and thus totally useless.
Can anyone else reproduce this?
https://bugzilla.redhat.com/show_bug.cgi?id=1359476
I don't think there's anything magical about it being 81M. I don't have this problem though with smaller files in the 1MB or less range. I just don't know at what threshold it becomes a problem.
On Sat, 23 Jul 2016 21:43:07 -0600 Chris Murphy lists@colorremedies.com wrote:
I'm having myriad problems with gedit and large text files. OK 81MB isn't really that large, it should be able to handle that without this much difficulty.
First, it takes a long time to open, more than a minute, and this is on an SSD. Next, it's doing some processing for a really long time after it loads the document, about 5-6 minutes, while the process consumes 100% CPU and the fans start running on high like I'm blowing my hair dry rather than reading a document.
But the actual problem is, at some point I click out of gedit, then back into gedit, and somehow the white background becomes black. So it's a sea of black text on a black background and thus totally useless.
Can anyone else reproduce this?
https://bugzilla.redhat.com/show_bug.cgi?id=1359476
I don't think there's anything magical about it being 81M. I don't have this problem though with smaller files in the 1MB or less range. I just don't know at what threshold it becomes a problem.
I don't normally use gedit, but I fired it up on a text file that is about 118 MB. It quickly shows the initial screen, but then seems to lock up the screen. When I look in top, it's using 100% of one CPU. But it isn't really using a lot of memory. The text shows as white on a black background. When I switch to a different workspace and back, the screen is completely black until I move the mouse, then it shows up as white on black. I see that there is a progress bar at the top of the screen, and it is moving very slowly, about the rate you reported.
So, yes, it appears that if I was using gedit I would have the problem also.
On Sat, Jul 23, 2016 at 10:15 PM, stan stanl-fedorauser@vfemail.net wrote:
So, yes, it appears that if I was using gedit I would have the problem also.
Thanks for that. What do you use? I found emacs/powerful editor in GNOME Software, but whether I use a trackpad or a mouse, it chirps and complains pretty much constantly about not supporting <double-mouse-6> is undefined, <triple-mouse-7> is undefined and so on. Otherwise, when I open the same text file as gedit, it opens immediately, it scrolls without delays, I can reposition the window without it jerking, there are no screen redraw problems, and it uses maybe 25% CPU for about 10 seconds at the start of opening the file. So... I'd say gedit has problems. For a default text editor, meh...
---- Chris Murphy
On Sun, 24 Jul 2016 14:01:08 -0600 Chris Murphy lists@colorremedies.com wrote:
On Sat, Jul 23, 2016 at 10:15 PM, stan stanl-fedorauser@vfemail.net wrote:
So, yes, it appears that if I was using gedit I would have the problem also.
Thanks for that. What do you use?
I use vim. I know, a modal editor? Yeah, it has a learning curve, but once I got used to it, it is just so efficient. And even though I know I only use part of its capability, I don't regret biting the bullet. Most people hate the ESC thing to switch modes, but I mapped unlikely two character sequences to do the same thing, so I rarely need to hit escape. Some people go so far as to buy a foot switch to switch modes, so they become extremely efficient on the keyboard.
Usually, when I'm looking at such large text files they are output, and so I just use a pager like less to look at them since I'm reading them, not changing them
As further information, when I used gedit on a 77 MB file, it was ready with minimal delay (10 seconds?). I wonder if someone made an assumption about file size when allocating buffers, and used a less efficient method (temp file) when above a certain size. That would really slow things down. Haven't checked though.
On Sun, Jul 24, 2016 at 4:18 PM, stan stanl-fedorauser@vfemail.net wrote:
On Sun, 24 Jul 2016 14:01:08 -0600 Chris Murphy lists@colorremedies.com wrote:
On Sat, Jul 23, 2016 at 10:15 PM, stan stanl-fedorauser@vfemail.net wrote:
So, yes, it appears that if I was using gedit I would have the problem also.
Thanks for that. What do you use?
I use vim. I know, a modal editor?
I use vi which I guess on Fedora is vim, but this is in GNOME Terminal. All I really want is something I can scroll with a trackpad or pageup/pagedown neither of which works well in vi. I could just cat the text file and then do scrolling with Terminal, but...
I use vi which I guess on Fedora is vim, but this is in GNOME Terminal. All I really want is something I can scroll with a trackpad or pageup/pagedown neither of which works well in vi. I could just cat the text file and then do scrolling with Terminal, but...
Have you tried vim-X11, it's a GUI vim.
On Tue, 26 Jul 2016 09:30:46 -0600 Chris Murphy lists@colorremedies.com wrote:
I use vi which I guess on Fedora is vim, but this is in GNOME Terminal. All I really want is something I can scroll with a trackpad or pageup/pagedown neither of which works well in vi. I could just cat the text file and then do scrolling with Terminal, but...
less is my solution to that. I'm usually looking for a pattern in the output, and less allows that with the slash (/) command. Even regexes. And the space bar scrolls, as well as pgup / pgdn, and the scroll wheel works. Arrow keys move right and left if wrapping is turned off. Marks work like in vi(m), so it is easy to flip between positions to compare, once positions are marked. The best part is that it can be used as destination from a pipe and updated to see latest information while a process is running.
I've never used it without a keyboard, though, so it might be clumsy there. I just tried less with gnome terminal on a 65 MB file, and it worked great. When I tried it on the 118 MB file it did as well as konsole or a virtual console. That file has some really long lines (> 100k characters), so it takes some time to calculate output at the end when wrapping. When I tried it on a 136 MB file, all less than 80 columns, less in GNOME Terminal was instantaneous in flipping back and forth between start and end. So GNOME Terminal isn't the problem. Probably the design of the program for the rare case of extremely long lines requiring wrapping is causing the delay.
On Sun, Jul 24, 2016 at 2:08 PM, Joe Zeff joe@zeff.us wrote:
On 07/24/2016 01:01 PM, Chris Murphy wrote:
Thanks for that. What do you use?
You might try leafpad, from Xfce for a GUI editor.
Better. Same 100% CPU thing, doing something but I can't tell what, it is responsive while this is going on though, and no screen redraw problems like gedit.
On Tue, Jul 26, 2016 at 9:51 AM, Earl A Ramirez earlaramirez@gmail.com wrote:
I use vi which I guess on Fedora is vim, but this is in GNOME Terminal. All I really want is something I can scroll with a trackpad or pageup/pagedown neither of which works well in vi. I could just cat the text file and then do scrolling with Terminal, but...
Have you tried vim-X11, it's a GUI vim.
Starts out really good, loads the text file fast and I can scroll pretty much right away. But about 30 seconds later, 100% CPU madness. It quickly recovers. Then I scroll some more and 100% CPU and scrolling stalls out. Looks like this happens only when scrolling up (backwards) rather than down. Oh yay, scrolling up is basically not usable with a document of this size apparently.
So far less in GNOME Terminal is being the most cooperative but I'm really not at all familiar with it so navigation is a bit rudimentary at the moment.
Funny enough, cat <doc> in GNOME Shell gets me pretty much what I see in all of these other programs, a long 100% CPU burn cycle until it's done, I guess rendering, the file in Terminal. But scrolling is fast (I set the buffer to unlimited) and it uses next to no memory which is interesting now that I'm doing this on a 500MiB debug file...
On 07/26/2016 12:19 PM, Chris Murphy wrote:
On Sun, Jul 24, 2016 at 2:08 PM, Joe Zeff joe@zeff.us wrote:
On 07/24/2016 01:01 PM, Chris Murphy wrote:
Thanks for that. What do you use?
You might try leafpad, from Xfce for a GUI editor.
Better. Same 100% CPU thing, doing something but I can't tell what, it is responsive while this is going on though, and no screen redraw problems like gedit.
Well then, try using something like nano in a text console. That gives you a full screen editor but no GUI. If that works, it's probably your DE; if not, it may be related to some sort of memory leak.
On Tue, Jul 26, 2016 at 11:48 AM, stan stanl-fedorauser@vfemail.net wrote:
On Tue, 26 Jul 2016 09:30:46 -0600 Chris Murphy lists@colorremedies.com wrote:
I use vi which I guess on Fedora is vim, but this is in GNOME Terminal. All I really want is something I can scroll with a trackpad or pageup/pagedown neither of which works well in vi. I could just cat the text file and then do scrolling with Terminal, but...
less is my solution to that. I'm usually looking for a pattern in the output, and less allows that with the slash (/) command. Even regexes. And the space bar scrolls, as well as pgup / pgdn, and the scroll wheel works. Arrow keys move right and left if wrapping is turned off. Marks work like in vi(m), so it is easy to flip between positions to compare, once positions are marked. The best part is that it can be used as destination from a pipe and updated to see latest information while a process is running.
Less is more. This is pretty badass.
I've never used it without a keyboard, though, so it might be clumsy there. I just tried less with gnome terminal on a 65 MB file, and it worked great. When I tried it on the 118 MB file it did as well as konsole or a virtual console. That file has some really long lines (> 100k characters), so it takes some time to calculate output at the end when wrapping. When I tried it on a 136 MB file, all less than 80 columns, less in GNOME Terminal was instantaneous in flipping back and forth between start and end. So GNOME Terminal isn't the problem. Probably the design of the program for the rare case of extremely long lines requiring wrapping is causing the delay.
I don't know what it is. These btrfs debug files don't have many lines longer than 60 characters. A scant handful might be up to 80. The only thing I see that makes lines long are long file names.
On 07/26/2016 12:29 PM, Chris Murphy wrote:
On Tue, Jul 26, 2016 at 9:51 AM, Earl A Ramirez earlaramirez@gmail.com wrote:
I use vi which I guess on Fedora is vim, but this is in GNOME Terminal. All I really want is something I can scroll with a trackpad or pageup/pagedown neither of which works well in vi. I could just cat the text file and then do scrolling with Terminal, but...
Have you tried vim-X11, it's a GUI vim.
Starts out really good, loads the text file fast and I can scroll pretty much right away. But about 30 seconds later, 100% CPU madness. It quickly recovers. Then I scroll some more and 100% CPU and scrolling stalls out. Looks like this happens only when scrolling up (backwards) rather than down. Oh yay, scrolling up is basically not usable with a document of this size apparently.
So far less in GNOME Terminal is being the most cooperative but I'm really not at all familiar with it so navigation is a bit rudimentary at the moment.
Funny enough, cat <doc> in GNOME Shell gets me pretty much what I see in all of these other programs, a long 100% CPU burn cycle until it's done, I guess rendering, the file in Terminal. But scrolling is fast (I set the buffer to unlimited) and it uses next to no memory which is interesting now that I'm doing this on a 500MiB debug file...
I suspect the gedit stuff is reformatting and such based on font displays, line wrapping, etc. You're probably going to hit that with any large file or files with extra long lines. I also suspect the vim-X11 scrollback is due to having de-buffer data and re-seek back into the file (again, seeking for lines to "break" on), along with all the glorious (tongue in cheek) overhead Gnome brings to the party.
I gave up on Gnome. The developers tend to ignore what users request, make some really stupid (IMHO) decisions and it's an unconscionable resource hog. While it's sort of pretty, it sure as hell ain't worth it. I use Xfce or LXDE, mostly Xfce. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Hard work has a future payoff. Laziness pays off now. - ----------------------------------------------------------------------
-
Chris Murphy -
Earl Ramirez -
Joe Zeff -
Rick Stevens -
stan