Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unusual speed boost: size matters

webkit.org

Post reply on HN
Print view View original

61–70 of 74 posts

Re: Unusual speed boost: size matters

#61

Post by smackfu »

captainmuon wrote: post #53

Does anyone else find it crazy that the absolute size of WebCore is 38 MB? That's larger than the Linux kernel which includes a bunch of drivers. If I understand Webkit's architecture correctly, that doesn't even include chrome (the visible UI, not Google's browser), JavaScriptCore, platform specific glue, and especially no auxilliary files (certificates, icons, the "broken image" sign, ...). Sometimes I long for the…

Remember that the browser game is not just about features, but also about speed. And the fastest way to do something is often not the shortest code.

Re: Unusual speed boost: size matters

#62

Post by CoolGuySteve »

bzbarsky wrote: post #45
CoolGuySteve wrote: post #6

Earlier quoted context omitted.

I concur. When I was there, they were pretty clear that everything I made belonged to Apple (which was total bullshit according to California law), that nothing we made would ever be open sourced due to patent issues, and that I was to never say anything about the company in public. I wonder how their team could swing that culture without tripping over legal at every turn.

> and that I was to never say anything about the company > in public. This remains the case to a large extent. This makes working with Apple and Microsoft in standards groups a bit challenging at times, since they won't actually comment on whether they're even thinking about implementing a standard, or whether they would be willing to implement it as written, until they suddenly ship it. And if they're _not_ shipping…

Agreed. Apple's involvement with BluRay in particular was pretty hilarious.

Re: Unusual speed boost: size matters

#63

Post by extra88 »

dm2 wrote: post #60
Perceval wrote: post #46

Earlier quoted context omitted.

I think Apple is pretty well set on mobile browsing as the future growth market. They don't seem to mind cannibalizing desktop sales for iPads, iPhones, and iPod Touches. In mobile browsing, Safari has ~60% market share. As long as mobile browsing keeps growing, Safari will remain an important asset for Apple. http://www.netmarketshare.com/browser-market-share.aspx?qpri...

I'm not sure I trust that site, they also claim that IE had 56% of the Desktop market share during 2013, while all other reports claim to have very different data: http://www.netmarketshare.com/browser-market-share.aspx?qpri... http://en.wikipedia.org/wiki/Usage_share_of_web_browsers Here is StatCounter for Mobile for the last 6 months, the iPhone browser with 23%: http://gs.statcounter.com/#mobile_browser-ww-monthly…

You just posted the netshare link again instead of a StatCounter one. StatCounter's Mobile OS shows iOS at about 24% last month. http://gs.statcounter.com/#mobile_os-ww-monthly-201207-20130...

But I don't think they count iPads and other tablets as "mobile." Their Mobile Browser chart listed iPhone and iPod touch separately and didn't list iPads at all. Mobile Screen Resolutions doesn't include iPad resolutions. Browser Versions (Partially Combined) has a separate entry just for Safari iPad (which actually exceeds Safari 6.0 and Safari 5.1, combined).

Re: Unusual speed boost: size matters

#64

Post by extra88 »

captainmuon wrote: post #53

Does anyone else find it crazy that the absolute size of WebCore is 38 MB? That's larger than the Linux kernel which includes a bunch of drivers. If I understand Webkit's architecture correctly, that doesn't even include chrome (the visible UI, not Google's browser), JavaScriptCore, platform specific glue, and especially no auxilliary files (certificates, icons, the "broken image" sign, ...). Sometimes I long for the…

I think a lot of what bulks up the rendering parts of the code is the handling of invalid web code. Not JavaScript, it's a programming language so throwing an error and stopping is expected behavior. But for HTML and CSS, browsers are expected to Do What I Mean, Not What I Wrote. If they only rendered valid code, they'd be a lot smaller.

But there are a lot of new APIs under the HTML5 umbrella. They're all accessed using JavaScript for some, a lot of the code will be in WebCore. Here's a bunch: http://www.netmagazine.com/features/developer-s-guide-html5-...

I'm sure Canvas and WebGL add a lot to WebCore.

Re: Unusual speed boost: size matters

#65

Post by captainmuon »

dragonwriter wrote: post #58
captainmuon wrote: post #53

Does anyone else find it crazy that the absolute size of WebCore is 38 MB? That's larger than the Linux kernel which includes a bunch of drivers. If I understand Webkit's architecture correctly, that doesn't even include chrome (the visible UI, not Google's browser), JavaScriptCore, platform specific glue, and especially no auxilliary files (certificates, icons, the "broken image" sign, ...). Sometimes I long for the…

> There are runtimes for NaCL, pNaCL, Flash, there's a PDF browser (some of these are plugins) Really? While Chrome has all of those built in, the other WebKit browsers don't so why would it be in the WebKit source tree (especially after the mutual purges of the Blink/WebKit split.) Also, all of those (except maybe the PDF viewer) in Chrome are plugins, and they are PPAPI (which was Chromium specific, not used by oth…

You're right, I mixed up WebKit and Chrome there.

Re: Unusual speed boost: size matters

#66

Post by nknighthb »

Someone wrote: post #30
nknighthb wrote: post #27

Earlier quoted context omitted.

Because some compilers do make use of that hint in useful ways. They're just not required to, nor are they required to do so in any specific situation, much like the register and volatile keywords.

volatile is not a hint, it's a requirement. You couldn't control hardware without it (compiler: "you're only writing this variable, never reading it. I'll skip those writes to speed things up". Programmer: "why isn't my program writing anything to this I/O port?")

I suggest reading the C standard, where you'll find that, despite the many words used about volatile, it doesn't really guarantee you anything at all. I especially love this sentence:

> "What constitutes an access to an object that has volatile-qualified type is implementation-defined."

The behavior of I/O ports and the meaning of any attempt to access them is beyond the scope of the standards. The "requirements" that exist for volatile are simply an absurdity outside the (new in C11/C++11) threading context, since the implementation is not actually required to do anything useful.

Re: Unusual speed boost: size matters

#67

Post by BenjaminPoulain »

DannyBee wrote: post #5

the updateCachedWidth example probably gives the wrong idea to a lot of folks. You would be just as well off making computeWidth const/pure/readonly/whatever The compiler can even detect if it modifies anything and mark it for you. In fact, better compilers will compute mod/ref information and know that m_cachedWidth is not touched over that call. However, LLVM's (which is what at least Apple is using) basic stateles…

Keep in mind the example is just there to illustrate a type of problems. The real use cases were obviously more complicated.

Some comments: The compiler does not do magic. If you call a virtual function or call an address from an other library, there is simply no way for the compiler to know the side effects at compile time.

The keyword "const" does not help the compiler to optimize this kind of code. Const is mostly a tool for developers, you can ignore it with mutable, const_cast, etc.

In many cases, the kind of code of the example will be optimized properly: -If the code is simple enough and all the functions are in the same compilation unit, Clang will figure out the dependencies and optimize it properly. -If the code is simple enough and the code is spread across several compilation units, Clang's link-time optimizer does an amazing job at finding dependencies.

The point of this example was more to illustrate a point about code clarity. We should not hesitate to make code more explicit, use extra temporary variables, etc. Those extra lines help both the other hackers and the compiler.

Re: Unusual speed boost: size matters

#68

Post by brigade »

DannyBee wrote: post #35
brigade wrote: post #15

Earlier quoted context omitted.

Wrong const. He's talking about the gcc function attribute extension, which most of the time is too strict, so recommending its general use isn't a great idea. C++ const has no effect on optimization, since it can be casted away. And being aware of aliasing issues is a good idea in general; nothing the compiler does can fix this in the general case (e.g. if computeWidth() is located in an external shared library it's…

"And being aware of aliasing issues is a good idea in general; nothing the compiler does can fix this in the general case (e.g. if computeWidth() is located in an external shared library it's basically impossible for the compiler to determine that it can't modify m_cachedWidth)" This is of course, false, it would be more accurate to say "in most open source compilers, ....". Doing compile/dynamic link/ analyze based…

Link time for shared libraries is run-time, so unless you're advocating everything be JITed the compiler still cannot know in the general case whether an external function modifies random memory.

1. I'm relatively sure that const member functions are still allowed to write into pointers that could potentially lead back to the object.

2. No way to know that just from the source. No way to know it's a member function either - if it isn't then 1. is irrelevant.

Re: Unusual speed boost: size matters

#69

Post by othermaciej »

dm2 wrote: post #42

While I'm very appreciative of the contributions Apple made to the web with WebKit, most of the recent innovations and upkeep has been thanks to Google. What is the future of WebKit now that Blink has been introduced? Will Apple spend considerable resources keeping an open-source project at the bleeding-edge considering it doesn't really make them any money? Should Safari just be scrapped? It only accounts for http:/…

WebKit did fine before Google ever joined the project, and I'm sure it will do fine with them gone.

Re: Unusual speed boost: size matters

#70

Post by othermaciej »

bzbarsky wrote: post #45
CoolGuySteve wrote: post #6

Earlier quoted context omitted.

I concur. When I was there, they were pretty clear that everything I made belonged to Apple (which was total bullshit according to California law), that nothing we made would ever be open sourced due to patent issues, and that I was to never say anything about the company in public. I wonder how their team could swing that culture without tripping over legal at every turn.

> and that I was to never say anything about the company > in public. This remains the case to a large extent. This makes working with Apple and Microsoft in standards groups a bit challenging at times, since they won't actually comment on whether they're even thinking about implementing a standard, or whether they would be willing to implement it as written, until they suddenly ship it. And if they're _not_ shipping…

In the case of Web standards in particular, you can usually see the checkins in our public source tree well before we ship it. But per policy we will rarely publicly commit to shipping something or not ahead of time.
Post reply on HN