After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 496434 - gedit slow when opening not so big files
gedit slow when opening not so big files
Status: RESOLVED DUPLICATE of bug 172099
Product: gedit
Classification: Applications
Component: general
2.20.x
Other All
: Normal normal
: ---
Assigned To: Gedit maintainers
Gedit maintainers
Depends on:
Blocks:
 
 
Reported: 2007-11-13 13:11 UTC by Jan Hutař
Modified: 2008-03-18 06:59 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20



Description Jan Hutař 2007-11-13 13:11:56 UTC
Please describe the problem:
When I try to open not so big file (say 60MB), gedit eats a lot of my memory, system responses are quite slow and when gedit window appears, it takes quite a long time to display the whole file.

Steps to reproduce:
1. $ cat /dev/urandom | strings --all | dd of=/tmp/big.txt bs=1k count=60000   # do not know better way how to generate such a file :)
2. $ gedit /tmp/big.txt

Actual results:
gedit eats more then 70% of 2GB RAM and it takes more then 5 minutes before whole file is ready

Expected results:
gedit should use much less memory and CPU

Does this happen every time?
always

Other information:
These bugs could be related:

Bug 172099 – it takes too long to open big files
Bug 486393 – Opening a large file crashes gedit
Bug 489356 – System unresponsive when opening huge files in gedit

Maybe also these:

Bug 456667 – crash in Text Editor: opening a 1.6GB AVI file
Bug 462970 – crash in Text Editor: opening a large file (~1...
Bug 493274 – crash in Text Editor: open a file.
Comment 1 Pavel Šefránek 2008-03-17 17:56:42 UTC
Jan: Please do not open another bug report if there is a very similar one (if you want to expose your thoughts, please add them as comments to bug 172099).

*** This bug has been marked as a duplicate of 172099 ***
Comment 2 Jan Hutař 2008-03-18 06:59:40 UTC
Sorry for that, I just was not sure if it is the same problem. Thanks for looking at this.