Bug 86044 - Web Inspector: tracking of FileSystem API reads/writes seriously hinders inspector usability
Summary: Web Inspector: tracking of FileSystem API reads/writes seriously hinders insp...
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (Deprecated) (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-09 17:14 PDT by Ben Vanik
Modified: 2014-12-12 14:37 PST (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ben Vanik 2012-05-09 17:14:34 PDT
In my application I am performing many small reads/writes from a Web Worker using the HTML5 File System API. I'm using the file system as a semi-persistent cache for binary data as one would use a scratch file in a native app.
Recently the reads have started to get logged in the Inspector (at least in Chrome), and when the inspector is up my browser slows down to the point of being unusable. The culprit is the hundreds+ of 'Request URL:blob:http://....' logged bits in the Network panel of the inspector. Eventually the browser also consumes significantly more memory (as it's retaining every blob), making it difficult to track memory usage.
Basically, with this feature it's now impossible to run my app with the inspector up.

Can this be a setting that defaults to off? I am failing to see the immediate use of this information in complex applications that are doing anything more than reading text files, and it's seriously hindering my ability to develop my application.

I can build a repro to see if the performance impact only occurs when the reads happen from a Worker, but whatever the decision is it should be consistent.
Comment 1 Brian Burg 2014-12-12 14:37:51 PST
Closing as invalid, as this bug pertains to the old inspector UI and/or its tests.
Please file a new bug (https://www.webkit.org/new-inspector-bug) if the bug/feature/issue is still relevant to WebKit trunk.