Bug 165268 - Every WKWebView initialization spends a few milliseconds hitting the disk
Summary: Every WKWebView initialization spends a few milliseconds hitting the disk
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Tim Horton
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-01 13:13 PST by Tim Horton
Modified: 2016-12-01 14:37 PST (History)
6 users (show)

See Also:

Attachments
Patch (16.96 KB, patch)
2016-12-01 13:14 PST, Tim Horton 		no flags Details | Formatted Diff | Diff
Patch (19.97 KB, patch)
2016-12-01 13:56 PST, Tim Horton 		beidson: review+
Details | Formatted Diff | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Horton 2016-12-01 13:13:50 PST 
Every WKWebView initialization spends a few milliseconds hitting the disk
Comment 1 Tim Horton 2016-12-01 13:14:17 PST 
Created attachment 295883 [details]
Patch
Comment 2 Tim Horton 2016-12-01 13:16:31 PST 
By my measurement (on iOS), this cuts total time initializing 19 WKWebViews (after the first one) by ~4x (~8ms to ~2ms per view).
Comment 3 Tim Horton 2016-12-01 13:40:09 PST 
<rdar://problem/29010113>
Comment 4 Tim Horton 2016-12-01 13:56:59 PST 
Created attachment 295891 [details]
Patch
Comment 5 Brady Eidson 2016-12-01 14:04:57 PST 
Comment on attachment 295891 [details]
Patch

If I were somebody else, I might say try to keep any calculated path that's a CString as a CString as long as possible.

But I guess they all get converted to Strings eventually.
Comment 6 Tim Horton 2016-12-01 14:07:04 PST 
(In reply to comment #5)
> Comment on attachment 295891 [details]
> Patch
> 
> If I were somebody else, I might say try to keep any calculated path that's
> a CString as a CString as long as possible.
> 
> But I guess they all get converted to Strings eventually.

Yep. Also, stringByResolvingSymlinksInPath is used for similar things all over the place and goes right back to String.

I think if we wanted to do that we might want to have a special type just for that purpose.
Comment 7 Tim Horton 2016-12-01 14:31:54 PST 
https://trac.webkit.org/changeset/209212
Comment 8 Tim Horton 2016-12-01 14:37:30 PST 
Build fix in https://trac.webkit.org/changeset/209214