Closed Bug 29584 Opened 25 years ago Closed 17 years ago

Exponential time to open text files in the Editor

Categories

(Core :: DOM: Editor, defect, P3)

defect

Tracking

()

RESOLVED WORKSFORME
mozilla1.4beta

People

(Reporter: pierre, Unassigned)

References

Details

(Keywords: perf, Whiteboard: [see 28783])

Attachments

(1 file)

Tested with fairly recent (2 days old) builds on Mac and Windows. - Create a text file with about 50 small lines of text. - Give the file a ".html" extension - Open the file in the Editor ==> It goes fast - Give the file a ".txt" extension - open the file in the Editor ==> It's slow (a couple of seconds) - Increase the size of the file to about 150 lines - Keep the ".txt" extension and open in the editor ==> It's incredibly slow (10-15 seconds on G4 and PC) - Rename the file with a ".html" extension - Open it in Navigator or in the Editor ==> It goes fast Conclusion: the Editor is VERY slow with ".txt" files compared to ".html" files and it seems to be exponentially slower as the size increases, even for files as small as 150 lines of text.
Attached file The text file I used... (deleted) —
Keywords: perf
hand over to Simon
Assignee: brade → sfraser
Target Milestone: M15
This is covered under 28783, but i'll leave it open in case there are some other performance issues.
Status: NEW → ASSIGNED
Depends on: 28783
M16
Target Milestone: M15 → M16
M17 for perf.
Target Milestone: M16 → M17
Keywords: nsbeta3
Target Milestone: M17 → M18
setting to m19
Target Milestone: M18 → M19
Keywords: nsbeta3
please do not nominate for nsbeta3 -- this will be addressed after crashes, regressions, correctness and polish bugs have been resolved, all Composer perf bugs have been set to m19/m20
Whiteboard: [see 28783]
moving out ot future, will concentrate on this type of work post rtm
Target Milestone: M19 → Future
Performance -> 0.9.1
Target Milestone: Future → mozilla0.9.1
-> 0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Does my latest patch in 74656, along with a good environment setting for $BLOCK_FRAME_LINE_CACHE_THRESHOLD (25?) help this problem at all? I'll do some testing when I resurrect my build, but I thought I'd throw it out. (Kudos to rbs for tipping me off to this bug.)
This bug really sucks now that we can load big plain text files. I'll try shaver's patches.
simon, any results here with the patches?
Target Milestone: mozilla0.9.2 → mozilla1.0
sorry, this needs to go over to 1.0
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
removing myself from the cc list
Pre-sabbatical bug triage. ->jfrancis
Assignee: sfraser → jfrancis
Status: ASSIGNED → NEW
The trunk is the wave of the future!
Target Milestone: mozilla1.0.1 → mozilla1.1beta
The days of having a half dozen milestones out in front of us to divide bugs between seem to be gone, though I dont know why. Lumping everything together as far out as I can. I'll pull back things that I am working on as I go.
Target Milestone: mozilla1.1beta → mozilla1.2beta
migrating milestones now that there are more available. i'll pull these back as I work on them
Target Milestone: mozilla1.2beta → mozilla1.4beta
opens instanteous for me on Thinkpad T40 150 lines. 1200 lines is about 10 secs. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060516 SeaMonkey/1.0.2 similar results with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060625 SeaMonkey/1.5a
QA Contact: sujay → editor
Assignee: mozeditor → nobody
=> WFM
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: