Primary eng (and PM) emails
Summary
I would like to remove XSLT support from Blink. XSLT is a mechanism for applying an XSL transform to XML documents to produce a DOM. Although XSLT is widely supported by browsers, the feature has not become popular with web authors. Instead, authors appear to prefer using JavaScript to transform data into DOM.
A use counter measurement from the Chrome Beta channel indicates that less than 0.02% of page views use XSLT. Moreover, less than 0.003% of page view use the XSLT processing instruction. (The balance use XSLT via the XSLTProcessor JavaScript API.)
XSLT is more often used on the server as part of an XML processing pipeline. Server-side XSLT processing will not be affected by deprecating and removing XSLT support in Blink.
Motivation
There are three motivations for removing XSLT support in Blink:
1) The XSLT implementation in Blink is "glued on" to the rest of Blink's machinery and introduces more than its share of complexity, which leads to security vulnerabilities.
2) XSLT support in Blink is the only client of libxslt in Chromium. Removing support for XSLT in Blink means that we can drop libxslt from the build, saving 561 kB of binary on desktop platforms and 250 kB of binary on Android.
3) Removing support for XSLT is a necessary step towards removing Blink's dependency on libxml. Over the long term, we would like to remove our dependency on libxml and re-use machinery from the HTML parser to implement high-performance handling of XML-based content.
Usage information from UseCounter
Removing support for XSLT will affect less than 0.02% of page views.
Compatibility Risk
This change poses a non-trivial amount of compatibility risk. XSLT is widely implemented in browsers, at varying degrees of quality. Web sites that rely on XSLT will break entirely without XSLT support in the browser and will need to be updated to perform their XSL transform on the server or to use a polyfill.
To mitigate this risk, I plan to remove support gradually. My first step will be to remove the API entry points (i.e., the XSLT processing instruction and the XSLTProcessor JavaScript API). We're able to make that change without causing too much incompatibility, I'll proceed to remove the guts of the implementation and libxslt from the build.
Row on feature dashboard?
I agree with the motivation and certainly 0.02% doesn't sound like much, but I do worry that there are still quite a lot of use-cases for local XML files e.g. output from CUnit tests is still in XML and rendered via an XSLT, various forms of machine generated output in XML, and I can also think of other things that render via XSLTs - that necessarily might not be seen in the metrics because they are either running locally or not on beta.
Presumably after this change, just the XML would render?
Yeah, I'm pretty concerned about intranet usage or other niche business applications. XSLT was the new hotness ~10 years ago, and I'm a tad worried about legacy systems that may still depend on it. It seems like we should definitely look at usage on stable channel.
What if we just replaced the C++ implementation with a JavaScript implementation that's loaded on-demand, permanently?
On Mon, Jul 22, 2013 at 9:51 PM, Dominic Mazzoni <dmaz...@chromium.org> wrote:
What if we just replaced the C++ implementation with a JavaScript implementation that's loaded on-demand, permanently?For my own interest, has this ever been done before?This sounds very useful..
Will dropping libxml and libxslt over time also cause issues with
respect to XPath support?
The BBC uses XSLT to provide user-friendly views of RSS feeds http://feeds.bbci.co.uk/news/rss.xml. Would be a shame to break that, as it might encourage them to remove user-facing RSS links. Is there an alternative to this use-case?
At one time Google Maps used XSLT; I don't know if it still does.
Primary eng (and PM) emails
Summary
I would like to remove XSLT support from Blink. XSLT is a mechanism for applying an XSL transform to XML documents to produce a DOM. Although XSLT is widely supported by browsers, the feature has not become popular with web authors. Instead, authors appear to prefer using JavaScript to transform data into DOM.
A use counter measurement from the Chrome Beta channel indicates that less than 0.02% of page views use XSLT. Moreover, less than 0.003% of page view use the XSLT processing instruction. (The balance use XSLT via the XSLTProcessor JavaScript API.)
XSLT is more often used on the server as part of an XML processing pipeline. Server-side XSLT processing will not be affected by deprecating and removing XSLT support in Blink.
Motivation
There are three motivations for removing XSLT support in Blink:
1) The XSLT implementation in Blink is "glued on" to the rest of Blink's machinery and introduces more than its share of complexity, which leads to security vulnerabilities.
2) XSLT support in Blink is the only client of libxslt in Chromium. Removing support for XSLT in Blink means that we can drop libxslt from the build, saving 561 kB of binary on desktop platforms and 250 kB of binary on Android.
3) Removing support for XSLT is a necessary step towards removing Blink's dependency on libxml. Over the long term, we would like to remove our dependency on libxml and re-use machinery from the HTML parser to implement high-performance handling of XML-based content.
Usage information from UseCounter
Removing support for XSLT will affect less than 0.02% of page views.
I probably don't have much legitimacy posting here, but I would suggest not removing XSLT processing capability at all.
Technical documentation people who build automated systems around structured document (SGML/XML) processing may rely on a standard like XSLT on the client to transform or stylize outputs. The idea of XML as SGML deliverable on the web is not dead to people in some corporate/organizational circles. Removing it from Chrome sounds like you'd be taking a web debugging/previewing tool away from people's toolboxes, even if most XSLT is done on the server side.
Also, how do you polyfill XML files that have a processing instruction when the XML itself doesn't have a script tag?
XSLT is not my first choice, but it's definitely a useful tool in my toolbox that would be very noticeable if suddenly missing.
Re-implementing XSLT would be a large project.
XSLT is historically derived from DSSSL, a monsterously large layout/transformation standard, designed by committee, whose demo implementation (jade) took one programmer (James Clark) about what, 10 years to evolve? It is the largest binary I think I've ever seen in UNIX. It follows that any complete XSLT implementation would also be large. That may count for a lot more on cell phone implementations, as opposed to PCs.
Just throwing this out there, but would it make sense (or even be possible) to re-implement xslt processing in c++ without libxml/xslt? Make it a native, first class part of the platform..
On Wed, Jul 24, 2013 at 6:26 PM, <mile...@gmail.com> wrote:In other words make Blink the only browser on the planet to not support XSLT? Also, WebKit's XSLT is the slowest on the planet. Even IE6 runs rings around it. And the solution is to fall back to an even slower JavaScript polyfill?
Also, how do you polyfill XML files that have a processing instruction when the XML itself doesn't have a script tag?
When I tried running the transformation twice in a row, the time for
the second transformation went down to around 450ms, so about half of
the time was in loading the stylesheet and half in the transformation.
That's just a single test though, so I wouldn't conclude too much
without a proper benchmark.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Do these statistics include usage in intranets?
I know of large companies that heavily rely on browser side XSLT (in particular the processing instruction approach) to implement their intranet sites.
Concerning footprint:
- on windows the side of the libxslt.dll is 166,912 bytes which is just 0.35% of the 40MB chrome.dll. Is this saving worth the loss of a feature as poweful as browser side XSLT?
Concerning (3), the removal of the dependency on libxml:- would it be an option to implement the libxml interfaces based on the high performance xml parser you were mentioning? This would remove the dependency on the libxml implementation while still allowing to use libxslt as an XSLT engine.
Adam
IMHO The less 0.02% statistic is a somewhat disingenuous self fulfilling prophecy, Loosing XSL From Chrome would be big loss, since Chome's XSL Support is so poor to start with. Of course a better challenge for the Chrome engineers would be to fix their support of XSTL so it can handle basics like include(), import() and document() correctly. Then they might find that more sites use for it. Currently I am able to use IE and FF support of XSL to significantly offload UI construction from the server to the Browser, and I have no Browser specific code in my XSLT. However with Chrome I actually have to ship the XML and XSL back to browser to get required output...
Primary eng (and PM) emails
Summary
I would like to remove XSLT support from Blink. XSLT is a mechanism for applying an XSL transform to XML documents to produce a DOM. Although XSLT is widely supported by browsers, the feature has not become popular with web authors. Instead, authors appear to prefer using JavaScript to transform data into DOM.
A use counter measurement from the Chrome Beta channel indicates that less than 0.02% of page views use XSLT. Moreover, less than 0.003% of page view use the XSLT processing instruction. (The balance use XSLT via the XSLTProcessor JavaScript API.)
XSLT is more often used on the server as part of an XML processing pipeline. Server-side XSLT processing will not be affected by deprecating and removing XSLT support in Blink.
Motivation
There are three motivations for removing XSLT support in Blink:
1) The XSLT implementation in Blink is "glued on" to the rest of Blink's machinery and introduces more than its share of complexity, which leads to security vulnerabilities.
2) XSLT support in Blink is the only client of libxslt in Chromium. Removing support for XSLT in Blink means that we can drop libxslt from the build, saving 561 kB of binary on desktop platforms and 250 kB of binary on Android.
3) Removing support for XSLT is a necessary step towards removing Blink's dependency on libxml. Over the long term, we would like to remove our dependency on libxml and re-use machinery from the HTML parser to implement high-performance handling of XML-based content.
Usage information from UseCounter
Removing support for XSLT will affect less than 0.02% of page views.
Compatibility Risk
This change poses a non-trivial amount of compatibility risk. XSLT is widely implemented in browsers, at varying degrees of quality. Web sites that rely on XSLT will break entirely without XSLT support in the browser and will need to be updated to perform their XSL transform on the server or to use a polyfill.
To mitigate this risk, I plan to remove support gradually. My first step will be to remove the API entry points (i.e., the XSLT processing instruction and the XSLTProcessor JavaScript API).
We're able to make that change without causing too much incompatibility, I'll proceed to remove the guts of the implementation and libxslt from the build.
Row on feature dashboard?
No.I welcome your thoughts.
Adam
Before I even read the comments, I'd like to offer my two cents. I apologize if this is merely joining the choir.
[update: apparently I'm too optimistic about the popularity of XML]
I offer some feedback, in case a proper argument to drop XSLT is to be made, which this proposition clearly is not.
I operate under the assumption that "Blink' is the javascript engine or library used in the Chrome browser.
On Monday, July 22, 2013 11:55:15 PM UTC+2, Adam Barth wrote:Primary eng (and PM) emails
Summary
I would like to remove XSLT support from Blink. XSLT is a mechanism for applying an XSL transform to XML documents to produce a DOM. Although XSLT is widely supported by browsers, the feature has not become popular with web authors. Instead, authors appear to prefer using JavaScript to transform data into DOM.
This is untrue.
First, XSLT is immensely popular with web authors.
Second, how are JavaScript authors to transform XML without an XML Transformation engine such as XSLT?
Third, "transforming data into DOM" is the task of the XML Parser, not XSLT, as XSLT only operates on XML data,
be it DOM or SAX.
Finally, saying XSL transforms XML into a DOM merely shows that you are not clear on what these terms really mean.
A use counter measurement from the Chrome Beta channel indicates that less than 0.02% of page views use XSLT. Moreover, less than 0.003% of page view use the XSLT processing instruction. (The balance use XSLT via the XSLTProcessor JavaScript API.)
Are the sites visited with Chrome representative of the Internet?
How many of them are handheld devices, being served mobile-targeted versions of websites?
Whether the XSLT processing instruction is used is irrelevant. Generally, a HTML page is downloaded which then incorporates
XML data. The XSLT processing instruction is therefore not used on HTML documents.
XSLT is more often used on the server as part of an XML processing pipeline. Server-side XSLT processing will not be affected by deprecating and removing XSLT support in Blink.
Obviously not, and neither does switching to another browser.
What statistics are gathered on whether XSLT is used on server side software?
Are they significantly more than the statistics presented earlier?
Also, why is this relevant?
Motivation
There are three motivations for removing XSLT support in Blink:
1) The XSLT implementation in Blink is "glued on" to the rest of Blink's machinery and introduces more than its share of complexity, which leads to security vulnerabilities.
"Glued on" either means that it is a dynamically linked library, since it is clearly a distinct implementation, with an API that can be easily secured,
or that it is very much internally integrated with the rest of "Blink" (think spaghetti), which means it is extremely difficult to remove without breaking other functionality.
Either way this makes no sense.
I can appreciate, however, that a piece of unmaintainable software needs to be rewritten. However, removing key features in doing so is merely cutting corners.
Since I imagine Chrome is a key component in Android systems, and since Google is behind both, and counting the heads-down, swiping-people these days,
I am quite amazed that there are not enough resources available to implement and maintain a solid system that can place itself among it's peers in terms of quality and functionality.2) XSLT support in Blink is the only client of libxslt in Chromium. Removing support for XSLT in Blink means that we can drop libxslt from the build, saving 561 kB of binary on desktop platforms and 250 kB of binary on Android.
Are you joking?
What is 561 kb of shared memory compared to the at minimum 4 Chrome processes required to view the default home page,
each consuming anywhere from 40 to 90Mb RAM? (Yes, that's right, about 250MB RAM minimum - ridiculous by the way).
As for handhelds, they have gigabytes of space, so having 250kb on storage, only loaded when needed, is no problem either.
And, consider your 'polyfill' solution, which requires an XSLT engine written in Javascript. The source code is generally LARGER
than the compiled binaries, and will also require mobile users to download more code for website visits. Not to mention
the memory overhead of running interpreted code versus a very stable, very optimized, very well tested binary library.
3) Removing support for XSLT is a necessary step towards removing Blink's dependency on libxml. Over the long term, we would like to remove our dependency on libxml and re-use machinery from the HTML parser to implement high-performance handling of XML-based content.
So, this is what it's really about then.
Why build a parser, how efficient it may be, for a language that is designed to describe transformations of itself,
and remove this core feature? In that case, why use XML based languages at all - there surely are more efficient ways
to structure data.
Usage information from UseCounter
Removing support for XSLT will affect less than 0.02% of page views.
I didn't know the Internet was a democracy. ;-) Although, people are free to choose which browser to use.
By the way, don't forget that it will affect 100% page views of many, many sites.
Also, the UseCounter refers to a C header file giving a 404, and not to the statistics.
Compatibility Risk
This change poses a non-trivial amount of compatibility risk. XSLT is widely implemented in browsers, at varying degrees of quality. Web sites that rely on XSLT will break entirely without XSLT support in the browser and will need to be updated to perform their XSL transform on the server or to use a polyfill.
Not sure what you mean by polyfill - sounds like graphics rendering.
[update: just read http://remysharp.com/2010/10/08/what-is-a-polyfill/ ; sounds like 'portable library' to me;
But, as it says, it's a paste to patch up cracks. Cracks that this proposition introduces.]
First, not all webservers are capable of performing such transformations, be it for technical reasons,
or for security reasons. Consider embedding data from a social networking site; the user would not
want to the server to access the XML under the user's credentials.
Second, websites that employ XSLT on the client side will often also already employ it server side,
allowing to share stylesheets. It makes no sense for a website to use basic templating server
side and employ structured transformations client side. Such sites will often have good reason
to delegate some XSLT operations to the client side.
To mitigate this risk, I plan to remove support gradually. My first step will be to remove the API entry points (i.e., the XSLT processing instruction and the XSLTProcessor JavaScript API).
How is this gradual?
We're able to make that change without causing too much incompatibility, I'll proceed to remove the guts of the implementation and libxslt from the build.
So basically you're removing the steering wheel from the car and see if you get some complaints from the passengers?Row on feature dashboard?
No.I welcome your thoughts.Adam
Thank you, Adam, for offering me this space. I hope you have taken no offense, even though I've been quite critical.
You're apparently not considering XML to be a dead-end street, and probably assume it'll be around for a while.
After all, it's been popular longer than most of the well-known internet companies existing today.
I'm sure you're aware of the concept of distributed computing. You must have noticed the trend of increased
JavaScript usage on the client side, and the fact that most people carry around one or more very powerful
miniature computers these days ("pads" and "tablets" and what have you).
SInce a lot of computing is already being offloaded to the client side, if this trend continues, then at some point,
the overly heavy webservers will become much lighter, like a whiff in the cloud, merely providing the data
and the instructions to the browsers. It is then not inconceivable that XSLT processing will also be delegated
to the client side, something I've personally employed in many websites.
I'm quite certain that if XSLT support is removed from Chrome, that it's popularity will dwindle. I don't personally
use it, anyway, except to test my websites as I understand it is quite popular on handheld devices.
The only reason I speak up, is because I like the idea of a browser developed in close cooperation with a creative company
that has so much experience with the Internet, and is pioneering improvements. This is good as it sets an example
for the improvement of all.
However, the decision to remove XSLTProcessor support from JavaScript shows quite the opposite. If this decision
is made, Chrome will soon sink to the ranks of Internet Explorer, not standing out for being slow, but for being cripple.
Have you done a search on XSLTProcessor lately? Or searched for the number of sites offering the JavaScript XML
API descriptions? How many questions and followers on sites like stackoverflow?
Let's see. Saving 500kb, usually stored in a 4kb sector, on a terabyte disk, costing 100$, would saveThe binary savings from dropping libxslt is valuable.
about .000000046566 dollars. You'd need 21.74 million users to save a dollar.
Also, the diskspace usage is roughly the same as the initial RAM usage - around 278Mb for
a clean install. But I still don't think the 561kb/278Mb = 0.1% space savings makes up for losing XSLT.
Further, a Chrome 30 installation is 125Mb, whereas Chrome31 is 279Mb. That's a 154Mb increase.
Also, gzipping the installations yields 52Mb and 116Mb respectively.
There are definitely better ways to gain 'valuable savings'.
Perhaps, but we're nit-picking here, because 500kb is nothing. Visiting almost any page will generate more cache on disk than that. If space is so precious, why not make it optionional during installation, or strip it from the Android versions
As for handhelds, they have gigabytes of space, so having 250kb on
storage, only loaded when needed, is no problem either.
And, consider your 'polyfill' solution, which requires an XSLT
engine written in Javascript. The source code is generally LARGER
than the compiled binaries, and will also require mobile users to
download more code for website visits. Not to mention
the memory overhead of running interpreted code versus a very
stable, very optimized, very well tested binary library.
The difference is that only sites that use XSLT need to pay that cost. The trouble with rarely used features it that everyone needs to pay some cost for including them in the product. For every feature, there's a crossover point at which the usage is small enough that the aggregate costs outweigh the aggregate benefits.
during the build.
Plus, memory and storage grow exponentially, and XSLT hasn't changed in 15 years (as no browser really supports XSLT 2.0).
Further, a Chrome 30 installation is 125Mb, whereas Chrome31 is 279Mb. That's a 154Mb increase.
Also, gzipping the installations yields 52Mb and 116Mb respectively.
(Not sure when it'll clean it up though, I clicked 'upgrade' and when it was done, 'restart', a few days ago..._$ du -hcs c:/Program\ Files\ \(x86\)/Google/Chrome/Application/* 125M c:/Program Files (x86)/Google/Chrome/Application/30.0.1599.101 279M c:/Program Files (x86)/Google/Chrome/Application/31.0.1650.63 844K c:/Program Files (x86)/Google/Chrome/Application/chrome.exe 828K c:/Program Files (x86)/Google/Chrome/Application/old_chrome.exe 1.0K c:/Program Files (x86)/Google/Chrome/Application/VisualElementsManifest.xml 405M total$ du -hcs c:/Program\ Files\ \(x86\)/Google/Chrome/Application/31*/Installer 141M c:/Program Files (x86)/Google/Chrome/Application/31.0.1650.63/Installer
On 31 December 2013 04:23, Kenney <ken...@gmail.com> wrote:
Let's see. Saving 500kb, usually stored in a 4kb sector, on a terabyte disk, costing 100$, would saveThe binary savings from dropping libxslt is valuable.
about .000000046566 dollars. You'd need 21.74 million users to save a dollar.
Optimising binary size is mostly about download size and memory usage, not disk usage.
Also, consider mobile devices where storage is much more limited (e.g. older Android devices that don't have unified /data and /sdcard volumes, and thus may only have 1GB or less space for apps) and much more expensive.
Also, the diskspace usage is roughly the same as the initial RAM usage - around 278Mb for
a clean install. But I still don't think the 561kb/278Mb = 0.1% space savings makes up for losing XSLT.
Further, a Chrome 30 installation is 125Mb, whereas Chrome31 is 279Mb. That's a 154Mb increase.
Also, gzipping the installations yields 52Mb and 116Mb respectively.
There are definitely better ways to gain 'valuable savings'.
Really? If you know what they are, please tell us. We are interested in any binary size savings you can suggest.
I don't really need all those. A tar.gz of this is 5.4 Mb download-size savings.$ du -hcs Google/Chrome/Application/31.0.1650.63/Locales/ 19M Google/Chrome/Application/31.0.1650.63/Locales/ $ /bin/ls Google/Chrome/Application/31.0.1650.63/Locales/ | grep -v pak | cut -f1 -d'.'|xargs am ar bg bn ca cs da de el en-GB en-US es es-419 et fa fi fil fr gu he hi hr hu id it ja kn ko lt lv ml mr ms nb nl pl pt-BR pt-PT ro ru sk sl sr sv sw ta te th tr uk vi zh-CN zh-TW
Are both versions needed? (Also, there's lots of d3dcompiler dll's in c:/Windows/SysWOW64/; in my case up to _34; might want to use the shared directX libs?)$ du -hcs d3dcompiler* 2.1M d3dcompiler_43.dll 3.1M d3dcompiler_46.dll 5.1M total
Perhaps, but we're nit-picking here, because 500kb is nothing. Visiting almost any page will generate more cache on disk than that. If space is so precious, why not make it optionional during installation, or strip it from the Android versions
As for handhelds, they have gigabytes of space, so having 250kb on
storage, only loaded when needed, is no problem either.
And, consider your 'polyfill' solution, which requires an XSLT
engine written in Javascript. The source code is generally LARGER
than the compiled binaries, and will also require mobile users to
download more code for website visits. Not to mention
the memory overhead of running interpreted code versus a very
stable, very optimized, very well tested binary library.
The difference is that only sites that use XSLT need to pay that cost. The trouble with rarely used features it that everyone needs to pay some cost for including them in the product. For every feature, there's a crossover point at which the usage is small enough that the aggregate costs outweigh the aggregate benefits.
during the build.
Doesn't stripping it from the Android version create exactly the problem you are trying to avoid? i.e. the server having to detect which browser it is, and then serve up pre-translated content to browsers without XSLT support? I don't see how that would be any better for people who currently use XSLT than Chrome dropping it on all OSes.
Plus, memory and storage grow exponentially, and XSLT hasn't changed in 15 years (as no browser really supports XSLT 2.0).
Except on mobile devices, where we've recently put a lot of effort into fitting Chrome into devices with *less* memory than the devices we previously supported.
Available memory is growing very slowly in mobile still, and as low-end featurephones are replaced with low-end smartphones, mobile apps need to use *fewer* resources than in the past when they have run mostly on high-spec devices.
Hello,
On 2-1-2014 16:58, Torne (Richard Coles) wrote:
I don't really see a difference between download size and disk usage, except that generally the files downloadedOn 31 December 2013 04:23, Kenney <ken...@gmail.com> wrote:
Let's see. Saving 500kb, usually stored in a 4kb sector, on a terabyte disk, costing 100$, would saveThe binary savings from dropping libxslt is valuable.
about .000000046566 dollars. You'd need 21.74 million users to save a dollar.
Optimising binary size is mostly about download size and memory usage, not disk usage.
are compressed, whereas on disk they are not. So they are, at least in my mind, the same, and relate by compression ratio.
(And then there's disk usage generated by _using_ the software, such as cache - another topic).
Also, I don't see a real difference between memory usage and disk usage, as both are memory, only different in persistence
and speed - a difference that seems to be quickly disappearing, mostly on mobile devices. (but I'm well aware of the implications of the difference).
Ofcourse, and this is why it is generally acceptable that software for such devices is more limited in terms of functionality than their desktop counterparts. If Chrome is to abide by mobile limitations only, however, then there's probably much more
Also, consider mobile devices where storage is much more limited (e.g. older Android devices that don't have unified /data and /sdcard volumes, and thus may only have 1GB or less space for apps) and much more expensive.
that can be done, but it would lose some of it's desktop market share.(as pointed out by Dominic Mazzoni, this is incorrect:
Also, the diskspace usage is roughly the same as the initial RAM usage - around 278Mb for
a clean install. But I still don't think the 561kb/278Mb = 0.1% space savings makes up for losing XSLT.
Further, a Chrome 30 installation is 125Mb, whereas Chrome31 is 279Mb. That's a 154Mb increase.
The actual size of v31 is 138M, so the increase from v30 is 13Mb (or 26x XSLT ;-)Certainly. First, download size:
).
Also, gzipping the installations yields 52Mb and 116Mb respectively.
There are definitely better ways to gain 'valuable savings'.
Really? If you know what they are, please tell us. We are interested in any binary size savings you can suggest.
I don't really need all those. A tar.gz of this is 5.4 Mb download-size savings.$ du -hcs Google/Chrome/Application/31.0.1650.63/Locales/ 19M Google/Chrome/Application/31.0.1650.63/Locales/ $ /bin/ls Google/Chrome/Application/31.0.1650.63/Locales/ | grep -v pak | cut -f1 -d'.'|xargs am ar bg bn ca cs da de el en-GB en-US es es-419 et fa fi fil fr gu he hi hr hu id it ja kn ko lt lv ml mr ms nb nl pl pt-BR pt-PT ro ru sk sl sr sv sw ta te th tr uk vi zh-CN zh-TW
Are both versions needed? (Also, there's lots of d3dcompiler dll's in c:/Windows/SysWOW64/; in my case up to _34; might want to use the shared directX libs?)$ du -hcs d3dcompiler* 2.1M d3dcompiler_43.dll 3.1M d3dcompiler_46.dll 5.1M total
As for memory savings, the chrome.dll (26Mb) and chrome_child.dll (30Mb), I'm sure these can be further split up
into components and loaded only when needed. I read that you're already on that track though.
Is the Javascript Console (which is awesome btw; could use a 'show element in DOM' though), loaded by default?
Only webdevs use these, which there aren't that many of (and if there were, they'd love having XSLT ;-))
It's rather extensive and I assume that that means it's not very tiny.
Chrome uses about 41 + 6 threads plus 12 threads per tab. Each of these reserves/uses stack, and when memory is low,
causes significant disk paging. (the pages, even if they're not used, are still unavailable for the rest of the system, see
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686774%28v=vs.85%29.aspx).
On that topic, the reserved image size of a single-tabbed Chrome is over 1Gb (private bytes 253Mb, working set 230Mb though); the same applies here, especially for 32 bit systems. I don't know exactly what the OS overhead is on a thread,
but using less threads is definitely going to improve things.
I'm sorry for this short list; I'd have to dive into the code to be of further assistance in this area.
But, for the purposes of the topic at hand, maybe there's enough savings here to nullify the libxsl size objections?Thank for you making my point for me ;-)
Perhaps, but we're nit-picking here, because 500kb is nothing. Visiting almost any page will generate more cache on disk than that. If space is so precious, why not make it optionional during installation, or strip it from the Android versions
As for handhelds, they have gigabytes of space, so having 250kb on
storage, only loaded when needed, is no problem either.
And, consider your 'polyfill' solution, which requires an XSLT
engine written in Javascript. The source code is generally LARGER
than the compiled binaries, and will also require mobile users to
download more code for website visits. Not to mention
the memory overhead of running interpreted code versus a very
stable, very optimized, very well tested binary library.
The difference is that only sites that use XSLT need to pay that cost. The trouble with rarely used features it that everyone needs to pay some cost for including them in the product. For every feature, there's a crossover point at which the usage is small enough that the aggregate costs outweigh the aggregate benefits.
during the build.
Doesn't stripping it from the Android version create exactly the problem you are trying to avoid? i.e. the server having to detect which browser it is, and then serve up pre-translated content to browsers without XSLT support? I don't see how that would be any better for people who currently use XSLT than Chrome dropping it on all OSes.
(As I mentioned above), it's generally been acceptable that mobile versions of software are more limited than their desktop counterparts. But I'm pleased that this is disappearing, and that Chrome brings advanced desktop features to the mobile
landscape. It'd be a shame if they were removed.
The point I intended to make, is that 500kb is not objectionable on a desktop system, whereas I can imagine that would be on a mobile system.Yes, I saw that too.. my >10 year old iphone has more memory than a brand new samsung galaxy. Maybe Moore's law doesn't hold because there weren't any mobile phones back then ;-)
Plus, memory and storage grow exponentially, and XSLT hasn't changed in 15 years (as no browser really supports XSLT 2.0).
Except on mobile devices, where we've recently put a lot of effort into fitting Chrome into devices with *less* memory than the devices we previously supported.
Totally agree - less is more. I can fit an entire operating system in under 500kb, using the proper language ;-)
Available memory is growing very slowly in mobile still, and as low-end featurephones are replaced with low-end smartphones, mobile apps need to use *fewer* resources than in the past when they have run mostly on high-spec devices.
Thanks!
Kenney
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
[..]Comments inline.
☆PhistucK
Also, I believe a 500 KB of binary code does not necessarily map to 500 KB of RAM/memory. It may actually map to many times the binary code, unless I am mistaken.
I don't really need all those. A tar.gz of this is 5.4 Mb download-size savings.$ du -hcs Google/Chrome/Application/31.0.1650.63/Locales/ 19M Google/Chrome/Application/31.0.1650.63/Locales/ $ /bin/ls Google/Chrome/Application/31.0.1650.63/Locales/ | grep -v pak | cut -f1 -d'.'|xargs am ar bg bn ca cs da de el en-GB en-US es es-419 et fa fi fil fr gu he hi hr hu id it ja kn ko lt lv ml mr ms nb nl pl pt-BR pt-PT ro ru sk sl sr sv sw ta te th tr uk vi zh-CN zh-TW
I somewhat agree, but keeping them there provides for better user experience when switching languages, I guess.
Are both versions needed? (Also, there's lots of d3dcompiler dll's in c:/Windows/SysWOW64/; in my case up to _34; might want to use the shared directX libs?)$ du -hcs d3dcompiler* 2.1M d3dcompiler_43.dll 3.1M d3dcompiler_46.dll 5.1M total
_34 is irrelevant here, or else it would have been used (either bundled or not).
Also, I guess not everyone has them.
As for memory savings, the chrome.dll (26Mb) and chrome_child.dll (30Mb), I'm sure these can be further split up
into components and loaded only when needed. I read that you're already on that track though.
Loading components is costly in terms of speed (and of memory, I guess, but I am not sure). More overhead.
Is the Javascript Console (which is awesome btw; could use a 'show element in DOM' though), loaded by default?
Only webdevs use these, which there aren't that many of (and if there were, they'd love having XSLT ;-))
It's rather extensive and I assume that that means it's not very tiny.
The JavaScript console is a necessary part of the browser. The browser is also the SDK. You should be able to debug stuff.It would be immensely helpful to have Visual Studio running on any computer that runs your software when the user has an issue, for example. Since Visual Studio is an extremely large piece of software, this is not possible. The Developer Tools is much smaller, though, so (luckily), it can be bundled with the browser. You can see other browsers implementing the same kind of Developer Tool integration. Even Internet Explorer 11 now has an "Inspect element" context menu option turned on by default.It is an essential part of the browser.
[..]
OS overhead is on a thread,
but using less threads is definitely going to improve things.
Obviously, keeping everything low is better. However, these threads and processes are needed to keep the browser responsive at all (well, most) times. That is a trade off that the team has decided to take. More memory, but more responsive browsing experience. When a plugin crashes, usually the browser and even the tab that employed the plugin do not crash. Today this may be a given (which is why most of the browsers have much higher memory usage), but it was not so until Chrome came along (along with its memory bloat).
Yes, I saw that too.. my >10 year old iphone has more memory than a brand new samsung galaxy. Maybe Moore's law doesn't hold because there weren't any mobile phones back then ;-)Except on mobile devices, where we've recently put a lot of effort into fitting Chrome into devices with *less* memory than the devices we previously supported.
You probably meant something else here, as iPhone was not available ten years ago (or are you an Apple employee with very early access to devices? ;)).
Sure, we agree on that.
https://www.google.com/#q=xslt -> 3.7 million results.
https://www.google.com/#q=javascript -> 0.89 million results.
Is XPath support to be dropped with this as well? I haven't really heard of XPath being used much outside of XSLT; it does queries that CSS queries can't do (and vice versa),
On 2-1-2014 23:20, PhistucK wrote:
[..]Comments inline.
☆PhistucKWell, the term 'binary size' has been bantered about, and it's in fact quite meaningless, since a digital computer always employs binary code. Even source code is binary.
Also, I believe a 500 KB of binary code does not necessarily map to 500 KB of RAM/memory. It may actually map to many times the binary code, unless I am mistaken.
But I figure it means 'executable', say .exe or .dll (or .so).
Current executable formats, such as PE/COFF, ELF and what have you, are basically just CPU instructions and data, with minimal metadata to say where to load what in memory.
So, you can pretty much say that the size of the executable or library is the exact size it will have in memory, with two caveats:
1) segments on disk are generally 512 bytes sector aligned; in memory, this is often 4kb due to hardware paging, so, you might get 3.5kb slack here and here for code/data segments;
2) uninitialized static data segments (.bss) and stack are typically not stored, but allocated at load/run time.
Then ofcourse there's program behaviour which allocates memory, but this is due to what algorithm the code implements (the content of the binary, rather than it's size).
But, maybe the term means someting else here?
[..]Oh sure, it makes it possible to have 1 installer for the whole world.
I don't really need all those. A tar.gz of this is 5.4 Mb download-size savings.$ du -hcs Google/Chrome/Application/31.0.1650.63/Locales/ 19M Google/Chrome/Application/31.0.1650.63/Locales/ $ /bin/ls Google/Chrome/Application/31.0.1650.63/Locales/ | grep -v pak | cut -f1 -d'.'|xargs am ar bg bn ca cs da de el en-GB en-US es es-419 et fa fi fil fr gu he hi hr hu id it ja kn ko lt lv ml mr ms nb nl pl pt-BR pt-PT ro ru sk sl sr sv sw ta te th tr uk vi zh-CN zh-TW
I somewhat agree, but keeping them there provides for better user experience when switching languages, I guess.
But, if I may be a PITA for a sec, then an "i guess those 19Mb is nice to have for users that switch languages" should have some statistics to go along
with it that make those 19Mb definitely worth it when compared to a 500kb feature ;-)
Have you seen firefox/thunderbird's 'install new dictionary language'? It's pretty seamless, about three clicks and you're good to go, no need to restart or anything.Typo, I meant _43.
Are both versions needed? (Also, there's lots of d3dcompiler dll's in c:/Windows/SysWOW64/; in my case up to _34; might want to use the shared directX libs?)$ du -hcs d3dcompiler* 2.1M d3dcompiler_43.dll 3.1M d3dcompiler_46.dll 5.1M total
_34 is irrelevant here, or else it would have been used (either bundled or not).
They should, as they are part of DirectX. Chrome doesn't bundle all of DirectX AFAIK, so, it already relies on it being installed.Also, I guess not everyone has them.
Well, perhaps. But this is the eternal tradeoff, speed vs. size. And, it's the same mechanism that any operating system
As for memory savings, the chrome.dll (26Mb) and chrome_child.dll (30Mb), I'm sure these can be further split up
into components and loaded only when needed. I read that you're already on that track though.
Loading components is costly in terms of speed (and of memory, I guess, but I am not sure). More overhead.
uses, as each program is a loadable component. The only real overhead though is the filesystem overhead, other than
that it doesn't make a difference whether you load a dll or have it compiled in statically, as the binary loader must read
the segment tables and relocation tables anyway, be they in a single file or in multiple files. The time it takes to process
these is negligible compared to the time it takes to do disk IO.
Another advantage of shared libraries is that they're shared, which means it uses less memory if more than one task/program
uses it. And since the API has to be better defined, there's better functional separation leading to a cleaner architecture,
which means less development overhead.
Only for developers. Most people surfing the web don't even know what HTML is. I am not convinced that it is required to have a Javascript console and embedded debugger unless you know how to use them
Is the Javascript Console (which is awesome btw; could use a 'show element in DOM' though), loaded by default?
Only webdevs use these, which there aren't that many of (and if there were, they'd love having XSLT ;-))
It's rather extensive and I assume that that means it's not very tiny.
The JavaScript console is a necessary part of the browser. The browser is also the SDK. You should be able to debug stuff.It would be immensely helpful to have Visual Studio running on any computer that runs your software when the user has an issue, for example. Since Visual Studio is an extremely large piece of software, this is not possible. The Developer Tools is much smaller, though, so (luckily), it can be bundled with the browser. You can see other browsers implementing the same kind of Developer Tool integration. Even Internet Explorer 11 now has an "Inspect element" context menu option turned on by default.It is an essential part of the browser.
and can modify the page sources on the webserver. I don't think much people will be debugging javascript or CSS on their smartphones unless they're web developers.
Maybe the latest IE has it, but the previous one didn't - you had to install developer tools separately. Same goes for Firefox. Since those browsers have it as an add-on, it's not essential, nor necessary.
Before those tools existed, people were already building websites, and they did fine without them, again, it's hardly essential. But it's very nice to have, indeed, IF you use it.
[..]Well, plugins are indeed something that should run in their own context, but a thread uses the same data as the task, it just has a different stack, and if it corrupts the task's data (stack is pretty well protected if you use higher level languages) then using threads generally doesn't increase stability. But it all depends on the software architecture, and I know a lot of effort has gone into responsiveness so I assume that that can't be helped then (although, loading a large site, say facebook or io9.com on a pentium 4 with 1.5 Gb ram in Chrome is far from responsive).OS overhead is on a thread,
but using less threads is definitely going to improve things.
Obviously, keeping everything low is better. However, these threads and processes are needed to keep the browser responsive at all (well, most) times. That is a trade off that the team has decided to take. More memory, but more responsive browsing experience. When a plugin crashes, usually the browser and even the tab that employed the plugin do not crash. Today this may be a given (which is why most of the browsers have much higher memory usage), but it was not so until Chrome came along (along with its memory bloat).
[...]
You're right; it can't be more than 5.5 years old. I could've sworn i had it 10 years ago ;-) But still, that should amount to 64Gb being standard now..Yes, I saw that too.. my >10 year old iphone has more memory than a brand new samsung galaxy. Maybe Moore's law doesn't hold because there weren't any mobile phones back then ;-)Except on mobile devices, where we've recently put a lot of effort into fitting Chrome into devices with *less* memory than the devices we previously supported.
You probably meant something else here, as iPhone was not available ten years ago (or are you an Apple employee with very early access to devices? ;)).
And no, I was just an early adopter ;-)
Thanks, interesting stuff!
Well, the term 'binary size' has been bantered about, and it's in fact quite meaningless, since a digital computer always employs binary code. Even source code is binary.But I figure it means 'executable', say .exe or .dll (or .so).
Current executable formats, such as PE/COFF, ELF and what have you, are basically just CPU instructions and data, with minimal metadata to say where to load what in memory.
So, you can pretty much say that the size of the executable or library is the exact size it will have in memory, with two caveats:
1) segments on disk are generally 512 bytes sector aligned; in memory, this is often 4kb due to hardware paging, so, you might get 3.5kb slack here and here for code/data segments;
2) uninitialized static data segments (.bss) and stack are typically not stored, but allocated at load/run time.
Then ofcourse there's program behaviour which allocates memory, but this is due to what algorithm the code implements (the content of the binary, rather than it's size).
But, maybe the term means someting else here?
[..]Oh sure, it makes it possible to have 1 installer for the whole world.
I don't really need all those. A tar.gz of this is 5.4 Mb download-size savings.$ du -hcs Google/Chrome/Application/31.0.1650.63/Locales/ 19M Google/Chrome/Application/31.0.1650.63/Locales/ $ /bin/ls Google/Chrome/Application/31.0.1650.63/Locales/ | grep -v pak | cut -f1 -d'.'|xargs am ar bg bn ca cs da de el en-GB en-US es es-419 et fa fi fil fr gu he hi hr hu id it ja kn ko lt lv ml mr ms nb nl pl pt-BR pt-PT ro ru sk sl sr sv sw ta te th tr uk vi zh-CN zh-TW
I somewhat agree, but keeping them there provides for better user experience when switching languages, I guess.
But, if I may be a PITA for a sec, then an "i guess those 19Mb is nice to have for users that switch languages" should have some statistics to go along
with it that make those 19Mb definitely worth it when compared to a 500kb feature ;-)
Have you seen firefox/thunderbird's 'install new dictionary language'? It's pretty seamless, about three clicks and you're good to go, no need to restart or anything.Typo, I meant _43.
Are both versions needed? (Also, there's lots of d3dcompiler dll's in c:/Windows/SysWOW64/; in my case up to _34; might want to use the shared directX libs?)$ du -hcs d3dcompiler* 2.1M d3dcompiler_43.dll 3.1M d3dcompiler_46.dll 5.1M total
_34 is irrelevant here, or else it would have been used (either bundled or not).
They should, as they are part of DirectX. Chrome doesn't bundle all of DirectX AFAIK, so, it already relies on it being installed.Also, I guess not everyone has them.
Well, perhaps. But this is the eternal tradeoff, speed vs. size. And, it's the same mechanism that any operating system
As for memory savings, the chrome.dll (26Mb) and chrome_child.dll (30Mb), I'm sure these can be further split up
into components and loaded only when needed. I read that you're already on that track though.
Loading components is costly in terms of speed (and of memory, I guess, but I am not sure). More overhead.
uses, as each program is a loadable component. The only real overhead though is the filesystem overhead, other than
that it doesn't make a difference whether you load a dll or have it compiled in statically, as the binary loader must read
the segment tables and relocation tables anyway, be they in a single file or in multiple files. The time it takes to process
these is negligible compared to the time it takes to do disk IO.
Another advantage of shared libraries is that they're shared, which means it uses less memory if more than one task/program
uses it. And since the API has to be better defined, there's better functional separation leading to a cleaner architecture,
which means less development overhead.
Only for developers. Most people surfing the web don't even know what HTML is. I am not convinced that it is required to have a Javascript console and embedded debugger unless you know how to use them
Is the Javascript Console (which is awesome btw; could use a 'show element in DOM' though), loaded by default?
Only webdevs use these, which there aren't that many of (and if there were, they'd love having XSLT ;-))
It's rather extensive and I assume that that means it's not very tiny.
The JavaScript console is a necessary part of the browser. The browser is also the SDK. You should be able to debug stuff.It would be immensely helpful to have Visual Studio running on any computer that runs your software when the user has an issue, for example. Since Visual Studio is an extremely large piece of software, this is not possible. The Developer Tools is much smaller, though, so (luckily), it can be bundled with the browser. You can see other browsers implementing the same kind of Developer Tool integration. Even Internet Explorer 11 now has an "Inspect element" context menu option turned on by default.It is an essential part of the browser.
and can modify the page sources on the webserver. I don't think much people will be debugging javascript or CSS on their smartphones unless they're web developers.
Maybe the latest IE has it, but the previous one didn't - you had to install developer tools separately. Same goes for Firefox. Since those browsers have it as an add-on, it's not essential, nor necessary.
Before those tools existed, people were already building websites, and they did fine without them, again, it's hardly essential. But it's very nice to have, indeed, IF you use it.
[..]Well, plugins are indeed something that should run in their own context, but a thread uses the same data as the task, it just has a different stack, and if it corrupts the task's data (stack is pretty well protected if you use higher level languages) then using threads generally doesn't increase stability. But it all depends on the software architecture, and I know a lot of effort has gone into responsiveness so I assume that that can't be helped then (although, loading a large site, say facebook or io9.com on a pentium 4 with 1.5 Gb ram in Chrome is far from responsive).OS overhead is on a thread,
but using less threads is definitely going to improve things.
Obviously, keeping everything low is better. However, these threads and processes are needed to keep the browser responsive at all (well, most) times. That is a trade off that the team has decided to take. More memory, but more responsive browsing experience. When a plugin crashes, usually the browser and even the tab that employed the plugin do not crash. Today this may be a given (which is why most of the browsers have much higher memory usage), but it was not so until Chrome came along (along with its memory bloat).
[...]
You're right; it can't be more than 5.5 years old. I could've sworn i had it 10 years ago ;-) But still, that should amount to 64Gb being standard now..Yes, I saw that too.. my >10 year old iphone has more memory than a brand new samsung galaxy. Maybe Moore's law doesn't hold because there weren't any mobile phones back then ;-)Except on mobile devices, where we've recently put a lot of effort into fitting Chrome into devices with *less* memory than the devices we previously supported.
You probably meant something else here, as iPhone was not available ten years ago (or are you an Apple employee with very early access to devices? ;)).
And no, I was just an early adopter ;-)
Thanks, interesting stuff!
I'm using XSLT in <http://macrodocs.org/> to convert documents from XML to HTML. It doesn't have many users, but is useful as a demonstration that if different publishers make XML available in a standard format, readers can choose how they want the documents to be displayed, by altering the XSL and CSS. It all runs client-side, so there's no transformation on the server.As people have been recommending Saxon-CE, I've added it today as an alternative XSLT processor. I found that setting it up it wasn't well documented (which is probably why I hadn't tried it before), but it was straightforward enough to include. The downsides are that a) clients have to download around 1MB of extra code (vs the 561kb of binary being removed from Blink), and b) it adds over 1 second to the transformation time that was about 40ms using Chrome's native XSLT processor.Still, if the speed of Saxon-CE can be improved (or if there's no other option), I'd be ok with switching to using it, especially if there are security benefits: there are already differences between browser implementations of native XSLT processors, and it would be nice to have something that runs reliably cross-platform.For comparison, <http://macrodocs.org/?doi=10.7554/eLife.00003> (native) vs <http://macrodocs.org/?doi=10.7554/eLife.00003&xslt=saxonce> (Saxon-CE).Alf
On Monday, 22 July 2013 22:55:15 UTC+1, Adam Barth wrote:
Primary eng (and PM) emails
Summary
I would like to remove XSLT support from Blink. XSLT is a mechanism for applying an XSL transform to XML documents to produce a DOM. Although XSLT is widely supported by browsers, the feature has not become popular with web authors. Instead, authors appear to prefer using JavaScript to transform data into DOM.
A use counter measurement from the Chrome Beta channel indicates that less than 0.02% of page views use XSLT. Moreover, less than 0.003% of page view use the XSLT processing instruction. (The balance use XSLT via the XSLTProcessor JavaScript API.)
XSLT is more often used on the server as part of an XML processing pipeline. Server-side XSLT processing will not be affected by deprecating and removing XSLT support in Blink.
Motivation
There are three motivations for removing XSLT support in Blink:
1) The XSLT implementation in Blink is "glued on" to the rest of Blink's machinery and introduces more than its share of complexity, which leads to security vulnerabilities.
2) XSLT support in Blink is the only client of libxslt in Chromium. Removing support for XSLT in Blink means that we can drop libxslt from the build, saving 561 kB of binary on desktop platforms and 250 kB of binary on Android.
3) Removing support for XSLT is a necessary step towards removing Blink's dependency on libxml. Over the long term, we would like to remove our dependency on libxml and re-use machinery from the HTML parser to implement high-performance handling of XML-based content.
Usage information from UseCounter
Removing support for XSLT will affect less than 0.02% of page views.
Compatibility Risk
This change poses a non-trivial amount of compatibility risk. XSLT is widely implemented in browsers, at varying degrees of quality. Web sites that rely on XSLT will break entirely without XSLT support in the browser and will need to be updated to perform their XSL transform on the server or to use a polyfill.
To mitigate this risk, I plan to remove support gradually. My first step will be to remove the API entry points (i.e., the XSLT processing instruction and the XSLTProcessor JavaScript API). We're able to make that change without causing too much incompatibility, I'll proceed to remove the guts of the implementation and libxslt from the build.
Row on feature dashboard?
No.
Primary eng (and PM) emails
Compatibility Risk
This change poses a non-trivial amount of compatibility risk. XSLT is widely implemented in browsers, at varying degrees of quality. Web sites that rely on XSLT will break entirely without XSLT support in the browser and will need to be updated to perform their XSL transform on the server or to use a polyfill.
I welcome your thoughts.
On 3 January 2014 00:20, Kenney <ken...@gmail.com> wrote:
Well, the term 'binary size' has been bantered about, and it's in fact quite meaningless, since a digital computer always employs binary code. Even source code is binary.But I figure it means 'executable', say .exe or .dll (or .so).
Current executable formats, such as PE/COFF, ELF and what have you, are basically just CPU instructions and data, with minimal metadata to say where to load what in memory.
So, you can pretty much say that the size of the executable or library is the exact size it will have in memory, with two caveats:
1) segments on disk are generally 512 bytes sector aligned; in memory, this is often 4kb due to hardware paging, so, you might get 3.5kb slack here and here for code/data segments;
2) uninitialized static data segments (.bss) and stack are typically not stored, but allocated at load/run time.
Then ofcourse there's program behaviour which allocates memory, but this is due to what algorithm the code implements (the content of the binary, rather than it's size).
The relationship between a binary's size on disk and its memory usage is immensely complicated and very difficult to reason about, because binaries are not loaded into memory all at once, they are paged on demand. Your assumptions here are mostly incorrect/irrelevant to the topic at hand.
When we use the term "binary size" we are referring generically to the combination of the portion of the download size that's caused by the code itself (as opposed to other kinds of data), the portion of the disk usage caused by the code itself, and also to the memory usage caused by paging the code itself (as opposed to the memory usage caused by the allocations the code makes at runtime). There are cases where these things increase and decrease somewhat independently of each other, or even in counter-intuitive ways (it's possible for a larger binary on disk to use less memory, and vice versa), but *generally* they all change in the same direction, such that it's reasonable to assume that reducing the size of the .exe or .dll will also reduce the other two by some amount.
So when we say that removing libxslt will reduce binary size by ~500kb we mean the install size will be ~500kb smaller, the download size will be <500kb smaller (due to compression) and the memory usage will be potentially smaller, but by what amount it's very hard to say (it's possible, though unlikely, that the memory saving would be *more* than 500kb if, for example, libxslt has a large bss section, or if it allocates memory in a path we hit during startup without having yet seen an XSLT page).
Oh sure, it makes it possible to have 1 installer for the whole world.I don't really need all those. A tar.gz of this is 5.4 Mb download-size savings.$ du -hcs Google/Chrome/Application/31.0.1650.63/Locales/ 19M Google/Chrome/Application/31.0.1650.63/Locales/ $ /bin/ls Google/Chrome/Application/31.0.1650.63/Locales/ | grep -v pak | cut -f1 -d'.'|xargs am ar bg bn ca cs da de el en-GB en-US es es-419 et fa fi fil fr gu he hi hr hu id it ja kn ko lt lv ml mr ms nb nl pl pt-BR pt-PT ro ru sk sl sr sv sw ta te th tr uk vi zh-CN zh-TW
I somewhat agree, but keeping them there provides for better user experience when switching languages, I guess.
But, if I may be a PITA for a sec, then an "i guess those 19Mb is nice to have for users that switch languages" should have some statistics to go along
with it that make those 19Mb definitely worth it when compared to a 500kb feature ;-)
While yes, it might be interesting to look at not bundling all the locales, they are not part of the binary size as we normally use the term; they affect the download/installed size, but only one is mapped into memory at a time (and may not be entirely present).
When we use the term "binary size" we are referring generically to the combination of the portion of the download size that's caused by the code itself (as opposed to other kinds of data), the portion of the disk usage caused by the code itself, and also to the memory usage caused by paging the code itself
[d3d_compiler]
As others have pointed out, if we bundle these libraries we do so for a reason; I don't know what that reason is because I know nothing about graphics, but it's unlikely to be a mistake or something we can easily avoid without giving up whatever capabilities they are providing.
I do trust that you all are very good at what you do, however, assuming you don't make mistakes and
Well, perhaps. But this is the eternal tradeoff, speed vs. size. And, it's the same mechanism that any operating system
As for memory savings, the chrome.dll (26Mb) and chrome_child.dll (30Mb), I'm sure these can be further split up
into components and loaded only when needed. I read that you're already on that track though.
Loading components is costly in terms of speed (and of memory, I guess, but I am not sure). More overhead.
uses, as each program is a loadable component. The only real overhead though is the filesystem overhead, other than
that it doesn't make a difference whether you load a dll or have it compiled in statically, as the binary loader must read
the segment tables and relocation tables anyway, be they in a single file or in multiple files. The time it takes to process
these is negligible compared to the time it takes to do disk IO.
Making things into more components is not a tradeoff between speed and size, it makes things slower *AND* larger:
calling code in a separate DLL takes *more* bytes than calling code in the same DLL. You are incorrect that it doesn't make a difference whether you load a DLL or have it compiled in statically; if you load a DLL there is at minimum one extra indirection on all cross-DLL accesses (some platforms have two extra indirections).
This has both a performance and size cost. Also, you mention relocation tables: having multiple DLLs increases the total size and processing time of the relocation tables, since if more than one of your libraries calls the same external functions they all end up with relocation entries referring to the same thing (i.e. duplication).
The time it takes to load a library and process its relocations is *not* negligible; most of the disk IO that happens at library load time happens *because* of the relocation processing;
if relocations weren't required then most of that IO won't happen at all, and will be deferred until the first time that page is required. On Android, it takes tens of milliseconds to load and relocate our single shared library; having more of them would make it slower *and* increase memory usage.
You don't appear to understand how paging or library loading works, which is a pretty critical thing to understand if you're going to comment on binary size and memory usage (in fact, you need to understand how it works on *all* the platforms we support, since the DLL model on Windows is very different from the shared object model on *nix).
"The relationship between a binary's size on disk and its memory usage is immensely complicated and very difficult to reason about, .."you state that that you are not qualified to assess whether or not I know how these things work and then proceed to not follow your own advice, making it harder for me to believe you as you apparently don't believe yourself.
Well, plugins are indeed something that should run in their own context, but a thread uses the same data as the task, it just has a different stack, and if it corrupts the task's data (stack is pretty well protected if you use higher level languages) then using threads generally doesn't increase stability. But it all depends on the software architecture, and I know a lot of effort has gone into responsiveness so I assume that that can't be helped then (although, loading a large site, say facebook or io9.com on a pentium 4 with 1.5 Gb ram in Chrome is far from responsive).OS overhead is on a thread,
but using less threads is definitely going to improve things.
Obviously, keeping everything low is better. However, these threads and processes are needed to keep the browser responsive at all (well, most) times. That is a trade off that the team has decided to take. More memory, but more responsive browsing experience. When a plugin crashes, usually the browser and even the tab that employed the plugin do not crash. Today this may be a given (which is why most of the browsers have much higher memory usage), but it was not so until Chrome came along (along with its memory bloat).
Threads are actually pretty cheap on modern systems, and you confuse different things: using multiple *processes* is mostly how we increase stability and security, and this has a significant memory cost (but one that we think is worth it).
Using many threads in each process is mostly how we ensure responsiveness, but there are occasionally reasons to use more threads for stability reasons as well: concurrency is difficult and it's much harder to reason about data structures if they are shared by multiple threads, so sometimes we introduce threads to own certain kinds of data/resources and be the exclusive user of them, and have other threads use message passing to make requests of the single owner thread. This doesn't require one thread per piece of data being handled in this way, but it also doesn't work well with threads having many responsibilities (since they can only be doing one thing at a time), so there is a tradeoff between responsiveness and memory usage here as well.
[]
At the end of the day, the maintenance cost and potential security risks of keeping a third party library integrated into our code is the real thing to be discussing;
I couldn't agree more!
winning back some binary size is nice, and a positive benefit, but you've spent a lot of time arguing against that specific reason (not all of it accurately)
and are overlooking the bigger picture :)
Hi Richard, team,
Thanks for your comments!
On the topic itself - removing XSLT support - I've not much more to say, as I am starting to agree,
mostly because of Victor.
However, I do have further comments on the topic of debating an argument.
I've learned a lot interacting with all of you these last few days (thank you!),
and I hope you'll take my words below in that same vein, either to strengthen your
views, or to allow your mind to change.
On 3-1-2014 15:41, Torne (Richard Coles) wrote:
Well, someone had to have implemented it, and it is really all pretty well defined. It's not black magic.On 3 January 2014 00:20, Kenney <ken...@gmail.com> wrote:
Well, the term 'binary size' has been bantered about, and it's in fact quite meaningless, since a digital computer always employs binary code. Even source code is binary.But I figure it means 'executable', say .exe or .dll (or .so).
Current executable formats, such as PE/COFF, ELF and what have you, are basically just CPU instructions and data, with minimal metadata to say where to load what in memory.
So, you can pretty much say that the size of the executable or library is the exact size it will have in memory, with two caveats:
1) segments on disk are generally 512 bytes sector aligned; in memory, this is often 4kb due to hardware paging, so, you might get 3.5kb slack here and here for code/data segments;
2) uninitialized static data segments (.bss) and stack are typically not stored, but allocated at load/run time.
Then ofcourse there's program behaviour which allocates memory, but this is due to what algorithm the code implements (the content of the binary, rather than it's size).
The relationship between a binary's size on disk and its memory usage is immensely complicated and very difficult to reason about, because binaries are not loaded into memory all at once, they are paged on demand. Your assumptions here are mostly incorrect/irrelevant to the topic at hand.
See, for example: http://en.wikipedia.org/wiki/Executable_and_Linkable_Format#Specifications
I don't see how this is any different from what I said, in response to 'incorrect/irrelevant', above.
When we use the term "binary size" we are referring generically to the combination of the portion of the download size that's caused by the code itself (as opposed to other kinds of data), the portion of the disk usage caused by the code itself, and also to the memory usage caused by paging the code itself (as opposed to the memory usage caused by the allocations the code makes at runtime). There are cases where these things increase and decrease somewhat independently of each other, or even in counter-intuitive ways (it's possible for a larger binary on disk to use less memory, and vice versa), but *generally* they all change in the same direction, such that it's reasonable to assume that reducing the size of the .exe or .dll will also reduce the other two by some amount.
But thank you for clarifying!Yes, that's right. So, the actual binary size of having libxslt is unknown? (I couldn't find it in http://neugierig.org/software/chromium/bloat/ nor in the program directory - statically linked perhaps?)
So when we say that removing libxslt will reduce binary size by ~500kb we mean the install size will be ~500kb smaller, the download size will be <500kb smaller (due to compression) and the memory usage will be potentially smaller, but by what amount it's very hard to say (it's possible, though unlikely, that the memory saving would be *more* than 500kb if, for example, libxslt has a large bss section, or if it allocates memory in a path we hit during startup without having yet seen an XSLT page).Now you're contradicting yourself:
Oh sure, it makes it possible to have 1 installer for the whole world.I don't really need all those. A tar.gz of this is 5.4 Mb download-size savings.$ du -hcs Google/Chrome/Application/31.0.1650.63/Locales/ 19M Google/Chrome/Application/31.0.1650.63/Locales/ $ /bin/ls Google/Chrome/Application/31.0.1650.63/Locales/ | grep -v pak | cut -f1 -d'.'|xargs am ar bg bn ca cs da de el en-GB en-US es es-419 et fa fi fil fr gu he hi hr hu id it ja kn ko lt lv ml mr ms nb nl pl pt-BR pt-PT ro ru sk sl sr sv sw ta te th tr uk vi zh-CN zh-TW
I somewhat agree, but keeping them there provides for better user experience when switching languages, I guess.
But, if I may be a PITA for a sec, then an "i guess those 19Mb is nice to have for users that switch languages" should have some statistics to go along
with it that make those 19Mb definitely worth it when compared to a 500kb feature ;-)
While yes, it might be interesting to look at not bundling all the locales, they are not part of the binary size as we normally use the term; they affect the download/installed size, but only one is mapped into memory at a time (and may not be entirely present).So I gather that the most important aspect of 'binary size' means the runtime memory footprint, then, something that I completely agree with.
When we use the term "binary size" we are referring generically to the combination of the portion of the download size that's caused by the code itself (as opposed to other kinds of data), the portion of the disk usage caused by the code itself, and also to the memory usage caused by paging the code itself
If that is so, then a simple 'LoadLibrary' or 'dlopen' call when XSLTProcessor is instantiated should reduce that footprint to 0
unless it is actually used. Not too hard to reason about.
I do trust that you all are very good at what you do, however, assuming you don't make mistakes and[d3d_compiler]As others have pointed out, if we bundle these libraries we do so for a reason; I don't know what that reason is because I know nothing about graphics, but it's unlikely to be a mistake or something we can easily avoid without giving up whatever capabilities they are providing.
defending a reason for doing something when you don't know that reason is hardly a sound argument.
The whole idea of having loadable components is that they are loaded when needed, and unloaded when they are no longer needed. In that case, you have a size benefit, and a slight speed loss. It's basically the same mechanism as disk-paging, where RAM usage is reduced incurring a speed penalty due to disk IO access.Well, perhaps. But this is the eternal tradeoff, speed vs. size. And, it's the same mechanism that any operating system
As for memory savings, the chrome.dll (26Mb) and chrome_child.dll (30Mb), I'm sure these can be further split up
into components and loaded only when needed. I read that you're already on that track though.
Loading components is costly in terms of speed (and of memory, I guess, but I am not sure). More overhead.
uses, as each program is a loadable component. The only real overhead though is the filesystem overhead, other than
that it doesn't make a difference whether you load a dll or have it compiled in statically, as the binary loader must read
the segment tables and relocation tables anyway, be they in a single file or in multiple files. The time it takes to process
these is negligible compared to the time it takes to do disk IO.
Making things into more components is not a tradeoff between speed and size, it makes things slower *AND* larger:
That depends on the linker you use. If a function pointer table is employed, then yes. But don't forget that all accessescalling code in a separate DLL takes *more* bytes than calling code in the same DLL. You are incorrect that it doesn't make a difference whether you load a DLL or have it compiled in statically; if you load a DLL there is at minimum one extra indirection on all cross-DLL accesses (some platforms have two extra indirections).
to those table entries are present in the relocation table, and the loader could write the values there directly, aswell.
The first part is not true. The amount of code is the same be they in a single object file or multiple, and all memory references are present in the relocation tables, be it a single table, or multiple.This has both a performance and size cost. Also, you mention relocation tables: having multiple DLLs increases the total size and processing time of the relocation tables, since if more than one of your libraries calls the same external functions they all end up with relocation entries referring to the same thing (i.e. duplication).
The last bit is true, as all code referencing the same memory address will indeed duplicate that memory address in their opcodes. But whether this is in one .text segment or several doesn't change the number of them.
Disk IO has nothing to do with relocation processing. Relocation processing operates on data in memory. Loading that data is the same as loading any other kind of data. The total amount of data loaded makes little difference, whether it be a single executable, or an executable and some DLLs: all the data must be loaded from disk anyway, and relocations must be processed.The time it takes to load a library and process its relocations is *not* negligible; most of the disk IO that happens at library load time happens *because* of the relocation processing;
Not necessarily. If you split the library in half, it'll take half as much time to load and relocate. Filesystem overhead on a memory storage device without moving parts is negligible (no heads need to move), in the context of reading a single file, or two files, from the same directory.if relocations weren't required then most of that IO won't happen at all, and will be deferred until the first time that page is required. On Android, it takes tens of milliseconds to load and relocate our single shared library; having more of them would make it slower *and* increase memory usage.
You'd have to measure the overhead, to be sure. I assume that the Android version of Chrome also has a < 1Mb executable loader with the main program in the dll. If you concatenate the two, I don't think you'd get much of a speed improvement in loading time because of the aforementioned reasons.
Is it now. They're both the same concept.You don't appear to understand how paging or library loading works, which is a pretty critical thing to understand if you're going to comment on binary size and memory usage (in fact, you need to understand how it works on *all* the platforms we support, since the DLL model on Windows is very different from the shared object model on *nix).
In your earlier comment,
"The relationship between a binary's size on disk and its memory usage is immensely complicated and very difficult to reason about, .."you state that that you are not qualified to assess whether or not I know how these things work and then proceed to not follow your own advice, making it harder for me to believe you as you apparently don't believe yourself.
That, or you do you know your stuff, and simply think I'm not capable of understanding it too.
But as you said, I only _appear_ to not know what I'm talking about to you, and looks can be deceiving.
However, for the sake of argument, let's assume that you're right, and that loading a DLL increases overhead significantly.
I think we can agree that in current website design trends, many javascript files have to be downloaded from different sites.
It is even proposed that adding another such shared library ("xsltprocessor.js") is preferable to having built-in support.
It would then seem that any objection used to defend the preference of a statically linked program over one consisting of multiple libraries, would be counted against using Javascript libraries, multiplied by each page load, multiplied by each script used on each page. This makes using javascript libraries exponentially worse than using a DLL (or a shared native binary), because not only does the file have to be loaded (either downloaded or read from cache), but it must be compiled and linked aswell.
[..]
Can you show me where I am confused about that?Well, plugins are indeed something that should run in their own context, but a thread uses the same data as the task, it just has a different stack, and if it corrupts the task's data (stack is pretty well protected if you use higher level languages) then using threads generally doesn't increase stability. But it all depends on the software architecture, and I know a lot of effort has gone into responsiveness so I assume that that can't be helped then (although, loading a large site, say facebook or io9.com on a pentium 4 with 1.5 Gb ram in Chrome is far from responsive).OS overhead is on a thread,
but using less threads is definitely going to improve things.
Obviously, keeping everything low is better. However, these threads and processes are needed to keep the browser responsive at all (well, most) times. That is a trade off that the team has decided to take. More memory, but more responsive browsing experience. When a plugin crashes, usually the browser and even the tab that employed the plugin do not crash. Today this may be a given (which is why most of the browsers have much higher memory usage), but it was not so until Chrome came along (along with its memory bloat).
Threads are actually pretty cheap on modern systems, and you confuse different things: using multiple *processes* is mostly how we increase stability and security, and this has a significant memory cost (but one that we think is worth it).
Yes! Sounds like all that is well covered!Using many threads in each process is mostly how we ensure responsiveness, but there are occasionally reasons to use more threads for stability reasons as well: concurrency is difficult and it's much harder to reason about data structures if they are shared by multiple threads, so sometimes we introduce threads to own certain kinds of data/resources and be the exclusive user of them, and have other threads use message passing to make requests of the single owner thread. This doesn't require one thread per piece of data being handled in this way, but it also doesn't work well with threads having many responsibilities (since they can only be doing one thing at a time), so there is a tradeoff between responsiveness and memory usage here as well.
I couldn't agree more![]
At the end of the day, the maintenance cost and potential security risks of keeping a third party library integrated into our code is the real thing to be discussing;
Well, that was the one that got the most responses. It just didn't make sense to me to remove a 168kb/500kb library when the program uses >1Gb virtual address space and around 250Mb RAM and call it valuable. Ofcourse, I'm biased, as I would like to see XSLT support remain, and so to me, that is more valuable than the 500kb RAM savings.winning back some binary size is nice, and a positive benefit, but you've spent a lot of time arguing against that specific reason (not all of it accurately)
I still don't think the space savings are a valid reason to drop the support because I have not seen a sound argument for it yet.
There may be a sound reason to drop XSLT support, but, I don't value false advertising - meaning, trumping up secondary reasons to support a decision only to make the case for it bulkier.
It makes the proposal seem weaker because it uses it's size to be convincing rather than it's argument. There's a much better reason to move in this direction than binary size.
Yes indeed :-)and are overlooking the bigger picture :)
Little did I know what I was stepping into :-)
I'm very grateful for all your comments, and I sure learned a lot.
The original proposal seemed off to me; the reasons listed didn't seem sound, and I attempted to remove the 'fluff', if you will, to get to the core of things and find a real solid reason.
Chrome is currently market leader, which means that it has a lot of influence on the direction the 'web' takes.
You're all very innovative, mostly know what you're talking about [ ;-) ], and I'm reassured that trust in your guidance is not misplaced.
I've definitely gotten a view of the bigger picture, and in that context it does make a lot of sense.
I just would like to suggest, if I may, to use your big picture in supporting your decisions and not
attempt to value bytes above the functionality that you offer your software's users. If a feature is
used often enough, it will cause it to become efficient - V8 being a point in case.
I thank you for your patience and willingness to interact!
Yours sincerely,
Kenney Westerhof
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.