Gedit takes many minutes to start if there are many files in directory

Bug #761781 reported by JohnWashington
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gedit (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

Binary package hint: gedit

Gedit takes forever (many minutes) to start up if there are a lot of files in the same directory. It also takes a similar time to exit.

I had about 70,000 small text files (each around 1K) in a directory. Double clicking on one in Nautilus resulted in many minutes before GEdit appeared. In contrast, other editors work instantly, e.g. nano, vim. Even Open Office opens any of these files quickly!

Perhaps http://ubuntuforums.org/showthread.php?t=922587&page=2 post #18 has a clue to why there is this horrendous delay.
"I think I know why it takes so long to load: How many files/folders does the directory you are trying to load have? gedit remembers the last directory, and it could be the fact that your last used directory has a lot of files/folders to be read."

It sounds as if GEdit is trying to be too clever, and whatever it's doing with the last used directory needs to be rethought. Though I don't think this is the complete explanation, because I believe this was the first time I'd tried to use GEdit in this directory.

Using Ubuntu 10.10.
gedit:
  Installed: 2.30.3-1ubuntu1
  Candidate: 2.30.3-1ubuntu1
  Version table:
 *** 2.30.3-1ubuntu1 0
        500 http://gb.archive.ubuntu.com/ubuntu/ maverick/main i386 Packages
        100 /var/lib/dpkg/status

Revision history for this message
JohnWashington (ubuntu-johnwash) wrote :

Further info. A friend has tried to repro this, as follows:
> I created 70K files in a directory and gedit opens normally on Mint. The
> file system is ext4. If I try and browse the files in "File->Open" or in
> the "File Browser" in the side panel it takes it's time to populate the
> browser, but starting and stopping seem fine to me.
>
> I do seem to have recreated the issue with an ext3 file system. Opening
> a file on the ext3 file system causes gedit to run at 100% on a core for
> about a minute, but only after a file on the ext3 file system. Once I
> went back to editing files on ext4, it worked as normal.

I'm using ext3. However, I would be very disappointed if this problem
were 'fixed' by saying I should install ext4. For example, Kate works
fine on my system with these files. (I use ext3 because some of the
tools on my older live CDs don't support ext4).

Revision history for this message
Michael Cunningham (mikee-cunningham) wrote :

Hello.

Please can you let us know if you still have this problem and if so try to reproduce the issue on a supported version of Ubuntu (preferably the latest - 15.10 Wily) and let us know if the problem is still present.

Thanks

Changed in gedit (Ubuntu):
status: New → Incomplete
Revision history for this message
JohnWashington (ubuntu-johnwash) wrote :

Hello Michael, thank you, perhaps I should be pleased that someone has responded to my report.

However, frankly my overwhelming reaction is that this is far too typical of how Ubuntu reports are handled. It goes like this:

* a report is filed.
* nothing is done about it, zip, nada, rien, not even a response.
* FOUR AND A HALF YEARS OF SILENCE
* "Hi, we're looking at your detailed report but we haven't made the slightest attempt to reproduce it"
* 60 days pass
* bug is closed, devs congratulate themselves on closing many bugs

Is this really the best we can do to get the community enthused and helping one another?

Revision history for this message
Michael Cunningham (mikee-cunningham) wrote :

Hi John.

I can certainly understand your frustration that there's been no response for a long time. Unfortunately, I'm not a dev, so I won't be much help in terms of actually fixing the problem. I just came across the bug and was interested in whether it still existed as there have been many updates to Ubuntu since you reported your problem.

I think what might be useful to see on this particular issue are some exact steps somebody can take to reproduce the issue you described.
For example,
Step 1. Install Ubuntu with an ext3 file system # or may be create an ext3 filesystem on an already installed system
Step 2. Create 70,000 small text files in a directory # if you had a particular method for creating the 70,000 1K text files, perhaps using a 'for' loop or similar - include this....
Step 3... and so on.

That way whoever looks at the bug can at least verify and confirm the issue you've described. With easy to follow reproducer steps using a more recent version of Ubuntu, I'd imagine it would be easier for someone to make progress with the bug.

FWIW, I was unable to reproduce this issue on a Trusty install but I use an ext4 fs and that, as you alluded to previously, may be a very important factor. Unfortunately, with my current set up I'm not able to test using ext3.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for gedit (Ubuntu) because there has been no activity for 60 days.]

Changed in gedit (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.