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 168139 - Wishlist: interactive editing of large files could be faster
Wishlist: interactive editing of large files could be faster
Status: RESOLVED FIXED
Product: meld
Classification: Other
Component: filediff
0.9.x
Other All
: Normal enhancement
: ---
Assigned To: Stephen Kennedy
Stephen Kennedy
: 344604 357459 473484 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-02-22 11:35 UTC by Duncan
Modified: 2009-07-28 08:54 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
First file (27.05 KB, text/plain)
2005-02-22 11:37 UTC, Duncan 		Details
Second file (106.61 KB, text/plain)
2005-02-22 11:39 UTC, Duncan 		Details

Description Duncan 2005-02-22 11:35:18 UTC 
The interacive edit/update gets pretty slow on larger files.

My worst one is an 800 line file which I merge with a 3000 line version
produced by my code generator and this is almost unsuably slow on my 1.8GHz
Athlon64. It takes about 4 seconds to: insert a char / paste some text /
transfer a diff fragment.

The files are attached below.
Comment 1 Duncan 2005-02-22 11:37:57 UTC 
Created attachment 37771 [details]
First file

Original version of file (800 lines)
Comment 2 Duncan 2005-02-22 11:39:24 UTC 
Created attachment 37772 [details]
Second file

Version produced by a code generator (2900 lines)
Comment 3 Stephen Kennedy 2006-06-13 20:48:27 UTC 
*** Bug 344604 has been marked as a duplicate of this bug. ***
Comment 4 Stephen Kennedy 2006-10-21 11:29:50 UTC 
*** Bug 357459 has been marked as a duplicate of this bug. ***
Comment 5 Cees Timmerman 2006-11-22 16:42:19 UTC 
Does this relate to the GUI? If so, it looks like it paints too much to me. Limiting repaints / refreshes of the tree to once per second should do. My Celeron 2.8 GHz is 65% occupied while diffing.
Comment 6 Stephen Kennedy 2006-11-22 20:55:34 UTC 
Nope, the computation of diffs is the expensive part, since it is done almost from scratch for each change.

Surprisingly, I couldn't find any relevant literature on incremental updates to diffs. I have a few ideas, but it's a fairly weighty piece of work.
Comment 7 Kai Willadsen 2008-09-13 16:49:09 UTC 
*** Bug 473484 has been marked as a duplicate of this bug. ***
Comment 8 Kai Willadsen 2008-09-13 16:56:25 UTC 
One possibility for improving interactive editing (without solving the incremental diff problem) is to throttle the diff updating process or, as suggested in Bug 514017, only start the process after a short period of inactivity. Would this be a reasonable compromise?
Comment 9 Kai Willadsen 2009-07-27 22:24:04 UTC 
With recent changes (see commits 12f3ba4 and 40b26c5) interactive editing should be much faster, so I'm going to close this bug. I'm sure that there are still some corner cases that trigger slowdowns; please open new bugs if you come across any. Thanks for the bug report.
Comment 10 Ross Burton 2009-07-28 08:54:04 UTC 
The main problem I had was editing via cut/paste.  It appeared that each character being pasted caused a recaclulation of the diffs, because if I pasted a hundred line block in a several thousand line file meld would lock up for several minutes.  This seems a lot better now, thanks!