| Summary: | Every WKWebView initialization spends a few milliseconds hitting the disk | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Tim Horton <thorton> | ||||||
| Component: | New Bugs | Assignee: | Tim Horton <thorton> | ||||||
| Status: | RESOLVED FIXED | ||||||||
| Severity: | Normal | CC: | andersca, bdakin, beidson, mitz, sam, simon.fraser | ||||||
| Priority: | P2 | ||||||||
| Version: | WebKit Nightly Build | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Attachments: |
|
||||||||
|
Description
Tim Horton
2016-12-01 13:13:50 PST
Created attachment 295883 [details]
Patch
By my measurement (on iOS), this cuts total time initializing 19 WKWebViews (after the first one) by ~4x (~8ms to ~2ms per view). Created attachment 295891 [details]
Patch
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.
(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. Build fix in https://trac.webkit.org/changeset/209214 |