Bug 20054 - Showing large plain-text files is extremely slow
Summary: Showing large plain-text files is extremely slow
Status: RESOLVED DUPLICATE of bug 31719
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC All
: P1 Major
Assignee: QtWebKit Unassigned
URL:
Keywords: Performance, Qt
Depends on:
Blocks: 35784
  Show dependency treegraph
 
Reported: 2008-07-16 07:45 PDT by Benjamin Meyer
Modified: 2010-03-10 17:21 PST (History)
5 users (show)

See Also:


Attachments
Large text file (345.83 KB, text/plain)
2009-12-02 02:13 PST, Jocelyn Turcotte
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Benjamin Meyer 2008-07-16 07:45:13 PDT
What steps will reproduce the problem?
1. dd if=/dev/urandom of=/tmp/test.txt bs=1024 count=256
2. go to uri file:///tmp/test.txt

What is the expected output? What do you see instead?
Mozilla shows this file in about 1 second.

QtWebKit from Qt 4.4

Please provide any additional information below.
Showing this file takes about 60 seconds on my machine.

I tracked down the issue to the fact that in bidi.cpp we are calling nextBreakablePosition over and over which constructs a QTextBoundryFinder
Comment 1 Benjamin Meyer 2008-07-16 07:50:06 PDT
I started hacking around and made a branch that passes all of the tests and re-uses the iterator when possible, but it is a bit of a hack and when you enable the other iterator caches there are three failures which doesn't make any sense...  And it can still crash an iterator is created, the string is deleted a new string is created at the same location in memory, but with a different lenght and a new iterator is created with it.  We should just see about re-using the same iterator upstream.

Branch:
http://code.staikos.net/cgi-bin/gitweb.cgi?p=webkit;a=shortlog;h=bmeyer/fasttext

Diff:
http://code.staikos.net/cgi-bin/gitweb.cgi?p=webkit;a=blobdiff;f=WebCore/platform/qt/TextBreakIteratorQt.cpp;h=94aafdba5e8fd2e261caa4b446756112e1a3c2c6;hp=88b96808650ed290ea328208157d2f965089d39e;hb=95c45c80fc64841cfc262facaba34750b9ca5138;hpb=af6eca2c5a5ec7e5a462ad211f8f1e3cb9bdef86
Comment 2 Benjamin Meyer 2008-07-16 09:22:37 PDT
Probably worth looking into what the average length is.  Maybe we could get rid of the buffer
Comment 3 Kenneth Rohde Christiansen 2009-10-04 07:31:33 PDT
There have recently been some commits that could improve this:

https://bugs.webkit.org/show_bug.cgi?id=29092

Can you tell me if this is still an issue?
Comment 4 Jocelyn Turcotte 2009-12-02 02:13:46 PST
Created attachment 44137 [details]
Large text file

Example generated using:
dd if=/dev/random bs=1024 count=256 | base64 > large.txt

The bug is still present, reloading this file locks the browser for 20 seconds, it loads instantly in firefox.
Comment 5 Jocelyn Turcotte 2010-03-03 06:12:00 PST
This bug has to be fixed for QtWebKit 2.0
Comment 6 Andreas Kling 2010-03-10 10:03:52 PST

*** This bug has been marked as a duplicate of bug 31719 ***
Comment 7 Benjamin Meyer 2010-03-10 11:52:35 PST
Shouldn't that one be a duplicate of this issue as this is the older issue?
Comment 8 Andreas Kling 2010-03-10 17:21:12 PST
I opted for keeping the other one since it had more useful information.