Intent to Deprecate and Remove: XSLT

8,563 views
Skip to first unread message

Adam Barth

unread,
Jul 22, 2013, 5:55:15 PM7/22/13
to blink-dev

Primary eng (and PM) emails

aba...@chromium.org


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

Eric Seidel

unread,
Jul 22, 2013, 6:00:47 PM7/22/13
to Adam Barth, blink-dev
I am *strongly* supportive of this change. Our XSLT code introduces
lots of complexity and has long been a source of security
vulnerabilities in WebKit and Blink.

I am the original author of XSLTProcessor for WebKit, as well as much
of WebKit's XSLT support (read: hacks).

I think there is a great opportunity for an enterprising JS author to
implement an XSLTProcessor poly-fill for these sites which depend on
XSLT. I suspect such a library could perform as well or better than
our native implementation.

Ojan Vafai

unread,
Jul 22, 2013, 6:24:12 PM7/22/13
to Eric Seidel, Adam Barth, blink-dev
LGTM

Emil A Eklund

unread,
Jul 22, 2013, 6:29:07 PM7/22/13
to Adam Barth, blink-dev
On Mon, Jul 22, 2013 at 2:55 PM, Adam Barth <aba...@chromium.org> wrote:
> A use counter measurement from the Chrome Beta channel indicates that less
> than 0.02% of page views use XSLT.

0.02% of all page views is a lot!
Do we have any data indicating whether any of the top 1,000 or 10,000
web sites use client side XSLT? If so it is probably worth reaching
out to them before removing support.

Aaron Boodman

unread,
Jul 22, 2013, 6:32:47 PM7/22/13
to e...@chromium.org, Adam Barth, blink-dev
That was my thought as well - 0.02% is a lot higher than I would have guessed.

- a

Dirk Pranke

unread,
Jul 22, 2013, 6:33:43 PM7/22/13
to Adam Barth, blink-dev
I'm not a big fan of XSLT generally or client-side XSLT in particular, but 0.02% (or even 0.003%) is still a pretty big number. Also, it seems likely that the beta channel underreports this to me, as enterprises are likely to be the main users of client-side XSLT in my experience, and they're not likely to be running the beta channel, I think (though both of those are just guesses).

I think I'd at least want to confirm this number on a stable release. It would also be interesting to know what we might recommend as an alternative for sites that will break if we drop this (e.g., something like IETab)?

-- Dirk

On Mon, Jul 22, 2013 at 2:55 PM, Adam Barth <aba...@chromium.org> wrote:

Eric Seidel

unread,
Jul 22, 2013, 6:36:47 PM7/22/13
to Dirk Pranke, Adam Barth, blink-dev
It looks like Google was even involved in the creation of such a
polyfill long ago:
https://code.google.com/p/ajaxslt/

w...@chromium.org

unread,
Jul 22, 2013, 7:40:27 PM7/22/13
to blin...@chromium.org
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?

Will

Elliott Sprehn

unread,
Jul 22, 2013, 7:46:04 PM7/22/13
to w...@chromium.org, blink-dev
On Mon, Jul 22, 2013 at 4:40 PM, <w...@chromium.org> wrote:
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?


I would hope most client side use cases could be fixed with JS libraries. Back in 2005 when people were trying to write XSLT in JS the speed of JS was very different than today.

I do think we should wait until this hits stable. I fear we're going to break a lot of corporate apps which would be sad since we just finally convinced lots of those people to switch to Chrome from IE7 (or 8 or...). :)

- E 

Darin Fisher

unread,
Jul 22, 2013, 9:53:29 PM7/22/13
to Elliott Sprehn, blink-dev, w...@chromium.org

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.

Dominic Mazzoni

unread,
Jul 23, 2013, 12:51:45 AM7/23/13
to Darin Fisher, Elliott Sprehn, blink-dev, w...@chromium.org
What if we just replaced the C++ implementation with a JavaScript implementation that's loaded on-demand, permanently?

Adam Barth

unread,
Jul 23, 2013, 12:58:11 AM7/23/13
to Dominic Mazzoni, Darin Fisher, Elliott Sprehn, blink-dev, w...@chromium.org
That might address motivation (1), but it's unclear whether a JavaScript implementation would let us remove our dependency on libxslt.

Adam

Rik Cabanier

unread,
Jul 23, 2013, 1:33:55 AM7/23/13
to Dominic Mazzoni, Darin Fisher, Elliott Sprehn, blink-dev, w...@chromium.org
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..

Adam Barth

unread,
Jul 23, 2013, 1:37:57 AM7/23/13
to Rik Cabanier, Dominic Mazzoni, Darin Fisher, Elliott Sprehn, blink-dev, w...@chromium.org
On Mon, Jul 22, 2013 at 10:33 PM, Rik Cabanier <caba...@gmail.com> wrote:
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..

Eric linked to this implementation earlier in the thread:


There's a comment at the top saying that the implementation is incomplete, however.

Adam

Rik Cabanier

unread,
Jul 23, 2013, 1:43:51 AM7/23/13
to Adam Barth, Dominic Mazzoni, Darin Fisher, Elliott Sprehn, blink-dev, w...@chromium.org
Sorry, what I meant to ask is if there are parts of the user facing APIs in the browser that are implemented as a javascript library (potentially calling into private APIs)

Adam Barth

unread,
Jul 23, 2013, 2:28:56 AM7/23/13
to Rik Cabanier, Dominic Mazzoni, Darin Fisher, Elliott Sprehn, blink-dev, w...@chromium.org
There are a number of examples in V8 and in the extension system.  We experimented with implementing Promises in JavaScript, but we gave up because doing so correctly was prohibitively difficult.  I haven't given up on the idea entirely, but it's extremely difficult to do correctly in the general case.

Adam

Rik Cabanier

unread,
Jul 23, 2013, 2:50:36 AM7/23/13
to Adam Barth, Dominic Mazzoni, Darin Fisher, Elliott Sprehn, blink-dev, w...@chromium.org
Interesting! Yeah, I thought promises were just going to be implemented in a JS layer.

Thanks for the info!

Jake Archibald

unread,
Jul 23, 2013, 11:50:31 AM7/23/13
to Rik Cabanier, Adam Barth, Dominic Mazzoni, Darin Fisher, Elliott Sprehn, blink-dev, w...@chromium.org
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?

TV. Raman

unread,
Jul 23, 2013, 11:53:55 AM7/23/13
to Adam Barth, blink-dev
Will dropping libxml and libxslt over time also cause issues with
respect to XPath support? There are many DOM access patterns
that are doable using XPath, that end up being clunky to
impossible using CSS queries --
--

--
> UseCounter<https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39>

PhistucK

unread,
Jul 23, 2013, 12:37:37 PM7/23/13
to TV. Raman, Adam Barth, blink-dev
XPath can be emulated using a JavaScript library that Google released some time ago -


PhistucK

Adam Barth

unread,
Jul 23, 2013, 12:43:51 PM7/23/13
to TV. Raman, blink-dev
On Tue, Jul 23, 2013 at 8:53 AM, TV. Raman <ra...@google.com> wrote:
Will dropping libxml and libxslt over time also cause issues with
respect to XPath support?

I don't believe we use libxml to implement XPath.  Instead, we implement XPath directly.

On Tue, Jul 23, 2013 at 8:50 AM, Jake Archibald <jakear...@chromium.org> wrote:
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?

Two alternatives are (1) to perform the transformation on the server using XSLT and (2) to perform the transformation on the client using JavaScript.

Adam

Emil A Eklund

unread,
Jul 23, 2013, 12:46:43 PM7/23/13
to Adam Barth, TV. Raman, blink-dev
On Tue, Jul 23, 2013 at 9:43 AM, Adam Barth <aba...@chromium.org> wrote:
>> 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?
>
> Two alternatives are (1) to perform the transformation on the server using
> XSLT and (2) to perform the transformation on the client using JavaScript.

Alternative one would not work for RSS feeds (or any type of xml
document that can be either displayed or interpreted) though.

Emil A Eklund

unread,
Jul 23, 2013, 12:53:22 PM7/23/13
to Adam Barth, TV. Raman, blink-dev
n Tue, Jul 23, 2013 at 9:46 AM, Emil A Eklund <e...@chromium.org> wrote:
> On Tue, Jul 23, 2013 at 9:43 AM, Adam Barth <aba...@chromium.org> wrote:
>>> 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?

Also, this use case seems rather common. In addition to the BBC the
The New York Times and CNN both use XSLT to render feeds as well.

T.V Raman

unread,
Jul 23, 2013, 12:56:10 PM7/23/13
to phis...@gmail.com, ra...@google.com, aba...@chromium.org, blin...@chromium.org
I remember playing with that a while ago -- not sure if that is a
complete implementation --- also do we have performance numbers
for it? The native implementation of XPath is fast in both Chrome
and Firefox --- and consequently, I suspect it's far more heavily
used than XSLT itself.

T.V Raman

unread,
Jul 23, 2013, 12:57:46 PM7/23/13
to aba...@chromium.org, ra...@google.com, blin...@chromium.org
That's good to know Adam! Thanks for the clarification --

Adam Barth

unread,
Jul 23, 2013, 12:58:25 PM7/23/13
to T.V Raman, PhistucK, blink-dev
This discussion is off-topic for this thread.  This thread is about XSLT.  If you'd like to discuss XPath, please create a new thread.

Adam

li...@holoweb.net

unread,
Jul 23, 2013, 6:43:37 PM7/23/13
to blin...@chromium.org
Note that there is currently no way for an XML document (other than XHTML or SVG) to run JavaScript. So the browser would need to support the xml-stylesheet processing instruction natively, regardless of the implementation language.

In principle we (W3C) could make an xml-script processing instruction, and "just get people to change their content"...

At one time Google Maps used XSLT; I don't know if it still does. I'd far rather see the XSLT and XPath APIs specified properly so that people can actually use the technology interoperably, and have some real test suites, although Web browsers today are stuck on XPath 1 from 1998; part of that ought to include the browsers moving to XPath 3, even if only a (documented) subset that's close to XPath 1, and same for XSLT 3.

roth...@google.com

unread,
Jul 23, 2013, 11:41:52 PM7/23/13
to blin...@chromium.org, li...@holoweb.net


On Tuesday, July 23, 2013 6:43:37 PM UTC-4, li...@holoweb.net wrote:
 
At one time Google Maps used XSLT; I don't know if it still does.

we haven't for years. we switched away from it because it was far too slow in practice. 

Adam Barth

unread,
Jul 24, 2013, 1:28:17 PM7/24/13
to blink-dev
Thanks to everyone who contributed to this thread.  It sounds like we should wait for data from the stable channel before deciding how to proceed here.

Thanks again,
Adam


On Mon, Jul 22, 2013 at 2:55 PM, Adam Barth <aba...@chromium.org> wrote:

Primary eng (and PM) emails

aba...@chromium.org


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.

ajcbo...@gmail.com

unread,
Jul 24, 2013, 2:37:47 PM7/24/13
to blin...@chromium.org
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.

Adam Barth

unread,
Jul 24, 2013, 2:48:40 PM7/24/13
to ajcbo...@gmail.com, blink-dev
On Wed, Jul 24, 2013 at 11:37 AM, <ajcbo...@gmail.com> wrote:
I probably don't have much legitimacy posting here, but I would suggest not removing XSLT processing capability at all. 

Please feel encouraged to contribute your perspective on threads like these.  The reason we have these discussions on a public mailing list is so that we can get input from a wide variety of people.
 
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.

I think everyone agrees that there are use cases for XSLT.  The question is how broadly the feature is used and whether it's pulling its weight in terms of security vulnerabilities and binary size.  When XSLT increases binary size and introduces security vulnerabilities, those costs are borne by all of our users, regardless of whether they enjoy the benefits of XSLT.  The less widely used XSLT is in the world, the worse that trade-off looks.  It's unclear what usage threshold will tip the scale one way or another in this case.  Hopefully data from the stable channel will be more enlightening.

Adam

hill...@gmail.com

unread,
Jul 24, 2013, 3:34:37 PM7/24/13
to blin...@chromium.org, ajcbo...@gmail.com
XSLT in the client is something I rarely used or relied on... until I got a Chromebook.  Now, having it there for tools like xml2rfc is useful indeed, especially as it is a piece of very powerful 'offline' functionality that just comes with the platform.

I wonder if it doesn't have a chance to become more useful and widely used, rather than continuing to decline, for that exact reason - to enable sophisticated behaviors from offline apps and extensions that are otherwise difficult to build with JavaScript or server-side processing.

-Brad Hill

da...@marshy.com

unread,
Jul 24, 2013, 5:58:47 PM7/24/13
to blin...@chromium.org
I have heavily used XSLT on the client-side for the past 10 years in the top 10 corporate companies in Australia in Intranet environments.

XSLT provides a clear separation of data from the HTML layout.

I don't understand why you would want to mix all of your HTML in JavaScript strings or JavaScript templating languages where you blur your data with your business logic and your templates for the visual display.

I build lots of apps with web services where JavaScript controls all the business logic to retrieve the data and XSLT keeps all of my HTML separated from the JavaScript logic so that it can transform that data.

Yes XSLT is a little more verbose (I use tools in my build process to minify and obfuscate my XSLT. 50% size reduction) than other templating languages but it is very easy to read and understand. This is one of the reasons I love XML and XSLT. Far less prone to errors and misunderstanding between developers and easier to understand the logic.

I also cache my XSLT files temporarily in the DOM cache so that subsequent transforms in a single page web app do no need to retrieve the XSLT files from the server.

I just wanted to state a few of my use cases so you can see the importance of XSLT on the client side.

I do understand you are trying to minimise security vulnerabilities in the browser so if there is better initiatives to replace the current code and the dependency on libxml I would like to see this happen rather then completely remove the ability to transform XSLT client side.

Thanks.

mile...@gmail.com

unread,
Jul 24, 2013, 8:26:33 PM7/24/13
to blin...@chromium.org
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?

XSLT is not my first choice, but it's definitely a useful tool in my toolbox that would be very noticeable if suddenly missing.

Jake

unread,
Jul 25, 2013, 12:05:37 AM7/25/13
to blin...@chromium.org
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..

PhistucK

unread,
Jul 25, 2013, 4:17:17 AM7/25/13
to Jake H, blin...@chromium.org
While everything is possible, the really low usage makes it not worth it, according to this intent.


PhistucK

Daniel Bratell

unread,
Jul 25, 2013, 7:59:12 AM7/25/13
to ajcbo...@gmail.com, Adam Barth, blink-dev
Den 2013-07-24 20:48:40 skrev Adam Barth <aba...@chromium.org>:

> I think everyone agrees that there are use cases for XSLT. The question
> is how broadly the feature >is used and whether it's pulling its weight
> in terms of security vulnerabilities and binary size. > When XSLT
> increases binary size and introduces security vulnerabilities, those
> costs are borne by >all of our users, regardless of whether they enjoy
> the benefits of XSLT. The less widely used XSLT >is in the world, the
> worse that trade-off looks. It's unclear what usage threshold will tip
> the >scale one way or another in this case. Hopefully data from the
> stable channel will be more >enlightening.

It's obvious from the numbers in this thread that the footprint added by
the current XSLT implementation is excessively large but there is also the
option to reimplement it. I know from experience (Presto) that an XSLT
engine can be *much* smaller and also faster than the numbers cited here.
And before anyone suggest something, Presto's XSLT engine is not a
plug'n'play component that could be transferred to chromium as is so that
is not an option.

Anyway, if it turns out that a modern browser has to have xslt support,
then someone (maybe we at Opera, maybe someone else) ought to look at
making it smaller.

/Daniel

Alex Milowski

unread,
Jul 25, 2013, 11:44:38 AM7/25/13
to blink-dev
I spent some time over a year ago digging into alternatives for XSLT in WebKit.  In fact, what I wanted to look at was XSLT 2.0 support.  I found a lack of good options, with the right kind of licensing, disappointing. 

Also, building your own XSLT processor that performs well is a fairly good sized engineering effort.  

Given the poor XSLT support in most browsers, I'm really not surprise more people don't use XSLT.  There are too many bugs between the various browsers that prevent you from using XSLT properly.  You have to walk a very fine line and use fairly simplistic stylesheets.  Basically, if everyone ships something that is broken, do you really expect someone to use it?

Since then, Michael Kay has released SAXON CE as open-source [1].  This would be a great option for replacing XSLT processing just about everywhere. 

Obviously, for XML documents and proper implementation of the XML stylesheet PI, you'd have to have a wrapper that invoked a Javascript-based library.  I'm not certain if that design pattern has been used for anything else as of yet nor how acceptable that would be on certain platforms (e.g. mobile).

--
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics

ajcbo...@gmail.com

unread,
Jul 25, 2013, 1:58:49 PM7/25/13
to blin...@chromium.org, ajcbo...@gmail.com, Adam Barth, bra...@opera.com
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. 

If security is the concern, how much work would it take to make the existing XSLT an electable browser option that is turned off by default? 

Also, are the usage statistics you're getting from those who opt-in? Organizations who use structured markup heavily (like financial, defense) may not be opting-in for security reasons.

mr.gene...@gmail.com

unread,
Jul 25, 2013, 2:02:44 PM7/25/13
to blin...@chromium.org
If this would cause developers to not be able to load xml and xslt in javascript and run a transformation without a third party library, I am not in favor of this.  There is no standardized way to send highly organized data to the client in a DOM compliant manner.  HTML fragments cannot be sent to the browser in DOM, they have to be sent as text only, an error prone venture at best.  Elements produced on the page must be individually identifiable, even when multiple copies of the form exist that contain different data (think side by side comparison of records, and multiple record viewing and editing.)  Most Javascript developers use innerHTML in the extreme prompting no accountability and uniformity across an application.  Third party JS libraries cannot be trusted to not break, and most are obfuscated with little or no documentation, making patching difficult for end users of the libraries.  Maintainability of web applications is crippled by requiring all developers to "do it manually" in all instances, especially when most know little about the actual DOM and only use quick and dirty access functions.  Most Javascript developers do not even understand the basics of event driven programming or closures.

While the impact of this will be minimal in interactive web sites, it could be overwhelming for web applications.  Most developers do not understand the difference between the two.  Think model / view / controller and realize that a web application only uses HTML as a user interface / widget collection and uses a combination of JS / PHP / PERL and others for all processing, UI generation and manipulation, and storage access.  Client side XSLT allows a web application developer to guarantee the output of a transformation (especially to build forms an list tables) is formatted correctly in html in a manner that offers little difference to checking the HTML itself for errors and omissions.  It also allows any special "ID"ing to be done on the client side exclusively, and does not require telling the server that a record was closed and not changed.

If all processing is done in entirety on the server, it increases the server cost significantly by requiring more servers for a given number of users.  If some data specific processing is left to the client, the impact to each client is usually small and unnoticed, while the load removed from the server(s) can be significant.

In the end, until a universally accepted and implemented replacement standard that requires no application specific third party libraries to operate is in place, I think it would be a mistake to remove it.  There really is nothing that actually fills the role it plays with the advantages of interoperability, maintainability, and programmer error reduction.  The difference between an application architect and a normal programmer is that the architect must select design and implementation standards, and treat the developers below them as end users.  It is not intended as an insult to anyone, but the architect cannot assume the programmer was successful at putting pants on this morning...

As for the idea of a Javascript implementation provided by the browser and not a third party include, that is loaded on demand, I would say that is how it should be done in every browser.  So long as every browser follows the same standard.

Alex Milowski

unread,
Jul 25, 2013, 2:59:53 PM7/25/13
to blink-dev
On Thu, Jul 25, 2013 at 10:58 AM, <ajcbo...@gmail.com> wrote:
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. 

Historically, that's not really true.  Some of the same people were involved, including myself, but that's about it.

XSL's formatting objects share a heritage with DSSSL.

XSLT and its transformation mechanisms share very little with DSSSL with the exception of match patterns and even that is fairly incomparable at this point.

You're just mistaken.  You all should at the reasonably short period of time that XSLT 1.0 processors were developed.

The problem is that libxslt is a closed architecture, requires libxml, and doesn't fit well within the architecture of a modern web browser.

So, to reiterate, it isn't trivial to do but it isn't impossibly hard either.  It is a serious engineering effort, just like implementing SVG or MathML.  Meanwhile, we can take one off-the-shelf in Javascript that works really well (Saxon CE).

Alf Eaton

unread,
Jul 26, 2013, 2:39:33 AM7/26/13
to blin...@chromium.org
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.


Alf

Alex Milowski

unread,
Jul 26, 2013, 2:27:32 PM7/26/13
to Alf Eaton, blink-dev
An interesting data point would be to track the load vs transformation time:

var start = Date.now();

/* import the XSL stylesheet */
if (data.xslt == "saxonce") {
var processor = Saxon.newXSLT20Processor(xsl);
} else {
var processor = new XSLTProcessor();
processor.importStylesheet(xsl);
}
var loaded = Date.now();

/* transform the XML document to an XHTML fragment */
var fragment = processor.transformToFragment(dom, document);

if (typeof console != "undefined") {
        var end = Date.now();
console.log("XSLT processing took " + (end - start) + "ms, load "+(loaded - start)+"ms");
}

You should also be able to re-use the processor but that will not help you if you only need to do one transform.

Arunprasad Rajkumar

unread,
Jul 26, 2013, 4:10:50 PM7/26/13
to Alex Milowski, Alf Eaton, blink-dev
Google itself uses XSLT in some places it seems :). For example http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

li...@holoweb.net

unread,
Jul 26, 2013, 9:21:15 PM7/26/13
to blin...@chromium.org, ja...@jakeonthenet.com


On Thursday, July 25, 2013 12:05:37 AM UTC-4, Jake H wrote:
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..

Note that libxslt is already in C and is moderately fast, although it implements XSLT 1 from 1998, not the more recent XSLT 2 or the XSLT 3 draft. It's in C. But it duplicates quite a bit of functionality that's already in the browser.

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?

We'd have to add one probably. Existing content would all break.
 

Alf Eaton

unread,
Jul 27, 2013, 7:24:20 AM7/27/13
to Alex Milowski, blink-dev
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.

dav...@gmail.com

unread,
Aug 1, 2013, 2:57:11 PM8/1/13
to blin...@chromium.org, Alex Milowski
On Saturday, 27 July 2013 12:24:20 UTC+1, Alf Eaton wrote:
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.


From the outset the timing results seems respectable for a JavaScript plugin. It would to good to see where the bottleneck is/are.

One of the great things about Saxon-CE is its interoperability with JavaScript and also its ability to work independently. In particular, the handling of events can all be done from  within stylesheet, extending the use of XSLT. 

plak...@gmail.com

unread,
Aug 3, 2013, 5:42:10 AM8/3/13
to blin...@chromium.org
I've been using XSLT/XML in the browser a lot and used only the ECMAScript xslt processor to transform data.
I'm sorry to say, but WebKit(Blink?) has got the worst of them all. Using the ECMAScript xslt processor to transform data has been a major plus. I've been able to transfer server processes to the browser/client. To give you 1 result: I didn't need a better/stronger new server.

>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.
What's a web author? Someone who writes w3c specs?
Anyway, I think the reason why it's not so popular is because it has missed twitter, YouTube and perhaps Google IO and it's equivalent. It has never been hyped.
Yes it has been implemented in all major browsers, but only up to version 1.0 which makes it less attractive to xslt/xml developers to use it.
I suggest to keep and improve the implementation up to version 2.0. Let the Opera team do it.

Please do not gradually remove the support. Just replace it with a better one.

>0.02% of all page views is a lot!
Indeed!


Op maandag 22 juli 2013 23:55:15 UTC+2 schreef Adam Barth:

tred...@blueyonder.co.uk

unread,
Aug 17, 2013, 7:29:42 PM8/17/13
to blin...@chromium.org
I would expect all modern web browsers to support XSLT on the desktop, and increasingly in mobile devices. As others have said, it can be used to make a clean separation of concerns between data formats and presentation. Where possible, an XSLT for XML to HTML/SVG/MathML/X3D transformation should generally happen server-side, but client-side transformations can be useful when:
  1. the web application is packaged in a transferrable object, independent of host server environments (like a widget or learning materials object);
  2. the web application is offline and cached (the XSLT stylesheet can be downloaded to the device);
  3. sharing rapid prototypes of a web application, where the browser does the work.
Some XSLT transformations on the other hand are probably best handled using JavaScript (as opposed to XML stylesheet declarations), where only part of DOM needs updated, or parameters are passed in from user input.

Because XSLT is a declarative language with a fairly limited vocabulary, I would have thought that the security implications should be fairly well understood compared to a procedural language, but I'm not a security expert. The value of a declarative language is possibly more in devolving optimization to the processor, in the way SQL works for example, and typically performance will improve over successive updates.

The familiarity of web developers with JavaScript over XSLT does not make the former the best solution in all cases. I agree with others on the list that if some problems with XSLT support in browsers were fixed, it would make it even more attractive. In particular, if XSLT stylesheets were able to import as the standard allows, that can make for an extremely scalable and flexible application (I assume single-domain restrictions). And I would not take a single (actually surprisingly high) snapshot statistic of usage as much of an argument. When did HTML5 or SVG views pass 0.02%? Did we kill support off then?

Thanks anyway for raising this important issue. I don't pretend to understand the other presumably very sound reasons for your proposal.

msh61...@gmail.com

unread,
Aug 18, 2013, 12:54:16 AM8/18/13
to blin...@chromium.org
I think removing dependency on libxml and libxslt is a good idea but XSLT itself must be implemented natively.
Removing XSLT from Blink is oppose to backward capability.

Adam Barth

unread,
Sep 5, 2013, 7:41:31 PM9/5/13
to blink-dev
To update this thread, we now have the following information from the stable channel:

0.0088% of page views use XSLProcessingInstruction
0.0126% of page views use XSLTProcessor

These numbers are consistent (and a bit lower) with the usage data from the stable channel.

Adam


On Mon, Jul 22, 2013 at 2:55 PM, Adam Barth <aba...@chromium.org> wrote:

Alex Russell

unread,
Sep 5, 2013, 7:46:17 PM9/5/13
to Adam Barth, blink-dev
That's exciting to hear. I support removing XSLT at our earliest convenience based on this evidence.


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

carste...@gmail.com

unread,
Oct 6, 2013, 8:05:08 AM10/6/13
to blin...@chromium.org, Adam Barth
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.

Cheers
Carsten

Adam Barth

unread,
Oct 6, 2013, 12:37:51 PM10/6/13
to carste...@gmail.com, blink-dev
On Sun, Oct 6, 2013 at 5:05 AM, <carste...@gmail.com> wrote:
Do these statistics include usage in intranets?

They do to the extent that the users in those intranets have opted in to sharing anonymous usage statistics.
 
I know of large companies that heavily rely on browser side XSLT (in particular the processing instruction approach) to implement their intranet sites.

If you take a look at <https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/k8aIeI6BCG0>, you'll see that I'm working to provide an alternative for folks in this situation.  The approach I'm currently investigating is creating an extension that implements XSLT functionality.  In an enterprise setting, the IT organization can push the extension to all of their Chrome installs using our enterprise tools.

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?

According to my measurement, the footprint is larger:

"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."

We can save more than just libxslt.dll.  We can also save all the code that integrates with libxslt.
 
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.

Unfortunately that's not possible.  The libxslt code depends directly on libxml data structures.  Notice the extensive use of xmlDocPtr and xmlNodePtr in libxslt's API.

Adam

cjgall...@gmail.com

unread,
Oct 10, 2013, 10:15:49 AM10/10/13
to blin...@chromium.org
I maintain a large website, on which we use XSLT extensively due to the fact that it allows us to have our HTML generation in a format that is supported both server-side (where it is rendered on the initial page request so that search engines can see it) and client-side (where the JS re-renders it when data changes on our websocket stream)

One of the reasons we decided to choose XSLT as a technology was its cross-browser support, the fact that it is supported all the way back from IE6 to the latest versions of Chrome/Firefox/Safari/IE.

It's very worrying that you're considering removing it from Chrome; replacing it with a JS library is not an option as the performance is not acceptable with those libraries; and an optional browser extension is equally not acceptable as 99% of our users would not have it installed.

By all means, if it would clean the Blink codebase then move this out of the core code, but at the very least it should be provided in an extension which is installed and enabled by default for all users.

smoerk

unread,
Oct 13, 2013, 10:17:34 AM10/13/13
to blin...@chromium.org
Adam,

your motivation is sound, but I still think XSLT is a great feature and I just started to using it on the client side. Chrome is one of big browser and deprecating XSLT in Chrome would kill XSLT for the Web. Just because there is no good XSLT implementation for the Google browser available, doesn't mean that XSLT isn't needed anymore. You are Google, you should have the resources to write a secure and fast XSLT 2.0 implementation ;).

smo...@gmail.com

unread,
Oct 18, 2013, 5:18:39 AM10/18/13
to blin...@chromium.org
Could Saxon-CE replace libxslt in Chromium?

Adam Barth

unread,
Oct 18, 2013, 12:06:46 PM10/18/13
to smo...@gmail.com, blink-dev
On Fri, Oct 18, 2013 at 2:18 AM, <smo...@gmail.com> wrote:
> Could Saxon-CE replace libxslt in Chromium?

I've been investigating that possibility. Unfortunately, Saxon-CE
doesn't seem to be able to handle all the XSLT content I tested. It's
possible I'm misusing the library, however.

Adam

Chris Evans

unread,
Oct 18, 2013, 3:43:22 PM10/18/13
to Adam Barth, smo...@gmail.com, blink-dev
Saxon-CE also probably hasn't had the years of security testing of libxml / libxslt, so would represent a risk in that regard. The exciting place to aim for from a security point of view is _no_ C-based implementation of XSLT exposed to the drive-by web.

Cheers
Chris

Adam Barth

unread,
Oct 18, 2013, 3:58:49 PM10/18/13
to Chris Evans, smo...@gmail.com, blink-dev
On Fri, Oct 18, 2013 at 12:43 PM, Chris Evans <cev...@chromium.org> wrote:
> On Fri, Oct 18, 2013 at 9:06 AM, Adam Barth <aba...@chromium.org> wrote:
>> On Fri, Oct 18, 2013 at 2:18 AM, <smo...@gmail.com> wrote:
>> > Could Saxon-CE replace libxslt in Chromium?
>>
>> I've been investigating that possibility. Unfortunately, Saxon-CE
>> doesn't seem to be able to handle all the XSLT content I tested. It's
>> possible I'm misusing the library, however.
>
> Saxon-CE also probably hasn't had the years of security testing of libxml /
> libxslt, so would represent a risk in that regard. The exciting place to aim
> for from a security point of view is _no_ C-based implementation of XSLT
> exposed to the drive-by web.

That's part of why I was excited about Saxon-CE. It's Java code
that's compiled to JavaScript with GWT.

Adam

Chris Evans

unread,
Oct 18, 2013, 3:59:59 PM10/18/13
to Adam Barth, smo...@gmail.com, blink-dev
Ah, I should learn how to use Google.
 

Adam

btu...@mulberrytech.com

unread,
Oct 24, 2013, 3:24:21 PM10/24/13
to blin...@chromium.org
While I agree that there is relatively little XSLT on the current Web I would like to respectfully suggest that the XSLT that is present is valuable, and that were there better support for XSLT on the web we would see a lot more of it.

For an example of an excellent use of XSLT on the web I suggest Archive's Finding Aids. For example:
http://library.gwu.edu/ead/rg0039.xml
or
http://library.gwu.edu/ead/ms2046.xml

In the case of Finding Aids, the advantages of this approach include providing an easily readable version of the content while also making the full richness of the information resource available.

Ian Hickson

unread,
Oct 24, 2013, 4:01:51 PM10/24/13
to btu...@mulberrytech.com, blin...@chromium.org
On Thu, 24 Oct 2013, btu...@mulberrytech.com wrote:
>
> For an example of an excellent use of XSLT on the web I suggest
> Archive's Finding Aids. For example:
> http://library.gwu.edu/ead/rg0039.xml
> or
> http://library.gwu.edu/ead/ms2046.xml
>
> In the case of Finding Aids, the advantages of this approach include
> providing an easily readable version of the content while also making
> the full richness of the information resource available.

This kind of thing happens all the time on the Web. The vast majority of
the time, the conversion into HTML is done on the server. That seems like
the better place for the conversion, since it lets the author use whatever
technology they prefer, lets them control it, lets them cache it, etc.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

wap...@wendellpiez.com

unread,
Oct 25, 2013, 5:14:06 PM10/25/13
to blin...@chromium.org
Hi,

I concur with others who have observed that use of XSLT on the web would be much stronger if browsers actually did a decent job supporting XSLT. They don't.

0.02% is 1/5000; I also think that's a lot given the poor support: artificial impediments such as disabling it by default; implementing only XSLT 1.0 (so 1999); security encumbrances that don't seem to apply elsewhere e.g. Javascript.

The main reason I keep a copy of Firefox around is that Chrome is such a pain to set up to run my XSLT. So I tell my customers to use Firefox (even though it's only marginally better). Consequently, Google doesn't get to see those numbers.

I agree with the post that suggests that Google should do this right. This should mean fixing features, not removing them.

Regards,
Wendell Piez
Message has been deleted

mark.d...@gmail.com

unread,
Nov 26, 2013, 9:08:48 PM11/26/13
to blin...@chromium.org, wap...@wendellpiez.com
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...

tree...@gmail.com

unread,
Dec 30, 2013, 5:40:21 PM12/30/13
to blin...@chromium.org
A very bad idea in my mind. Been using client-side XSLT for years, over time began noticing even mobile devices browsers support it. And now Chrome decides to remove it? And what's the alternative offered instead of this native built-in template solution? Javascript half-working implementations? Sure browsers had only XSLT 1.0 for years and it would have been nicer to have 2.0 too, but okay. More browsers support SVG and so there is more use for XSLT too. Few quirks here and there, but for most of the part it works rather well and fairly reliable in output, something I can't say for DOM stuff. So why remove something that works fairly well and is implemented in all major browsers?

ken...@gmail.com

unread,
Dec 30, 2013, 6:46:18 PM12/30/13
to blin...@chromium.org
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

aba...@chromium.org


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?

I just checked, and, no, this is indeed not posted April 1st... would've been a good one though!

Thank you for reading!

Yours sincerely,
  Kenney

Adam Barth

unread,
Dec 30, 2013, 8:24:02 PM12/30/13
to ken...@gmail.com, blink-dev
Hi Kenney,

On Mon, Dec 30, 2013 at 3:46 PM, <ken...@gmail.com> wrote:
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]

Thanks taking the time to share your perspective, but please take the time to read the existing discussion.  If folks reply without reading the existing posts, the discussion tends to go around in circles.

I've responded to some of your questions below.
 
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.

Blink is a library used by Chrome to implement HTML, SVG, CSS, and the DOM.  Most web standards are implemented in Blink (although a few are implemented in other libraries).

On Monday, July 22, 2013 11:55:15 PM UTC+2, Adam Barth wrote:

Primary eng (and PM) emails

aba...@chromium.org


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.

In these discussions, it's important to support statements like these with data.  Myself and others have made an effort to gather data about the usage of XSLT and a number of folks who have contributed to this discussion have provided examples of XSLT usage on the web.
 
Second, how are JavaScript authors to transform XML without an XML Transformation engine such as XSLT?

Most authors manipulate XML via the DOM.

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?

Not necessarily.  It's important to take this data in context.  For example, it's likely to underestimate usage in corporate intranets where employees are forced to use other browsers.
 
How many of them are handheld devices, being served mobile-targeted versions of websites?

We measured usage across desktop and mobile, and the usage of XSLT was roughly the same.  I would have expected the usage to be lower on mobile, but that doesn't appear to be the case.

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.

It's a relevant implementation issue because implementing the processing directive is what causes difficulty in the implementation.
 

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?

We haven't measured this quantity, but these uses of XSLT won't be disrupted if we removed XSLT support from Blink.
 
Are they significantly more than the statistics presented earlier?
Also, why is this relevant?

I included this information to make sure that folks understood that server-side use of XSLT won't be affected by this change.
 

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).

Memory usage is a complex topic.  Binary size doesn't correlate directly to RAM usage, although the two are related.  The binary savings from dropping libxslt is valuable.

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.
 

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.

The short answer is because XML is more widely used that XSLT, regardless of motivation of its designers.

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?

Unfortunately, the plan outlined in my email from July didn't work.
 

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.

I haven't taken any offense.  I understand that removing XSLT support will make some number of people unhappy.  Unfortunately, if we constrained ourselves to never making anyone unhappy, we'd have trouble building the best product that we can build.  There's a balance to be struck, and we're still searching for that balance.
 
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.

My personal view is that XML on the client is going to evolve over the coming years.  I expect that browsers will move to a simplified version of XML that doesn't support namespaces or internal DTD subsets because those features introduce vastly more complexity than they're worth.  Instead, I expect we'll process XML content using the "foreign content" HTML parsing algorithm, which, for example, is how we parse SVG content in HTML.

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.

Generally speaking, I share your observations, but rather than using XSLT to process data on the client, I expect most developers will use JavaScript.
 
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?

Yes, I've done all of those things.  Another interesting source of data is language usage on GitHub:


That data says that JavaScript is >500x as popular as XSLT.

Adam

Kenney

unread,
Dec 30, 2013, 11:23:00 PM12/30/13
to Adam Barth, blink-dev
Hi Adam,

Thanks for your response!

I've removed some parts you didn't comment on, to save you some diskspace.

On 31-12-2013 2:24, Adam Barth wrote:
> Hi Kenney,
>
> On Mon, Dec 30, 2013 at 3:46 PM, <ken...@gmail.com
> <mailto:ken...@gmail.com>> wrote:
>
> 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]
>
>
> Thanks taking the time to share your perspective, but please take the
> time to read the existing discussion. If folks reply without reading
> the existing posts, the discussion tends to go around in circles.
I have, hence the update, and I found my contribution not out of place
nor redundant, so I posted it.

> I've responded to some of your questions below.
>
> 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.
>
>
> Blink is a library used by Chrome to implement HTML, SVG, CSS, and the
> DOM. Most web standards are implemented in Blink (although a few are
> implemented in other libraries).
Thank you for clarifying that!

>
> On Monday, July 22, 2013 11:55:15 PM UTC+2, Adam Barth wrote:
>
> Primary eng (and PM) emails
>
> aba...@chromium.org
>
>
> 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.
>
>
> In these discussions, it's important to support statements like these
> with data. Myself and others have made an effort to gather data about
> the usage of XSLT and a number of folks who have contributed to this
> discussion have provided examples of XSLT usage on the web.
I appreciate that, but the source of the statistics is not clearly
mentioned (yes, the source-code, but that doesn't show me 0.02%), and
the biases have not been made clear.
For instance, how many people running chrome send usage statistics? What
demographic are they? Etc.

I did offer at the end some questions about searching for, for example,
XSLTProcessor, which yields 623.000 results.
I should say that that such queries give enough examples of use of XSLT.
There are many websites dedicated to this, for instance w3c, w3schools,
stackoverflow, MDN, etc.
I also thought it not necessary to point out the popularity of XSLT to
the people responsible for writing XSLT libraries.
I'm sure there was a reason to incorporate this functionality in the
first place.
Nor did I feel to contribute examples of XSLT usage, as most others have
already done this, and then what I had to say I would've been redundant.

But granted, popularity is a matter of preference.

> Second, how are JavaScript authors to transform XML without an XML
> Transformation engine such as XSLT?
>
>
> Most authors manipulate XML via the DOM.
I'd say all of them, since XSLT also manipulates the DOM. It's a bad
practice stemming from Javascript predating
XML, at which time only HTML was available, and no tree transformation
language had been designed.
Manipulating the page, they really had no choice but to use DOM, as this
can only be done once the page linking
the script is loaded, at which point transforming that particular DOM is
no longer useful.

I say though, that such manipulation is not really transformation, but
merely appending branches at predeclared
grafting points. And XSLT as invoked by JavaScript is used to format
these branches by translating a custom XML
format into (X)HTML.

> 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?
>
>
> Not necessarily. It's important to take this data in context. For
> example, it's likely to underestimate usage in corporate intranets
> where employees are forced to use other browsers.
Ofcourse.
Aswell as the fact that not everyone using Chrome runs Chrome Beta.
And that Chrome is a brand, and people who are brand oriented have
preferences, tastes, and will generally
exert those preferences in the kinds of sites they visit.

> How many of them are handheld devices, being served
> mobile-targeted versions of websites?
>
>
> We measured usage across desktop and mobile, and the usage of XSLT was
> roughly the same. I would have expected the usage to be lower on
> mobile, but that doesn't appear to be the case.
Well, I can't argue with that! :-)

Have you also normalized the stats over different sites? For instance,
most users will use a few sites very often,
say, google, gmail, facebook, twitter, youtube and such. Those few sites
might account for over 90% of the page loads,
giving a slightly skewed perspective.

Further, what's the ratio between desktop and mobile? About the same as
Chrome usage relative to the other browsers (almost 50%) given the
competition?

> 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.
>
>
> It's a relevant implementation issue because implementing the
> processing directive is what causes difficulty in the implementation.
It works fine, except for xsl:include/xsl:import, that I know of.

Ok. So, the processing instruction, which is used 0.003% according to
Chrome Beta statistics, is the culprit.
Relative to the 0.02%, this then means, that 15% of all pages that use
XSLT are problematic. And due to this,
it is deemed appropriate to drop support for the other 85% of the
sites/pages.

You know, I don't really see why it would be so hard to implement an xsl
processing instruction. You can even
write a stylesheet to do it. They're also generally mentioned before the
root tag, so no Javascript or DOM events have
been triggered yet.. Also, officially xsl stylesheet processing
instructions are only defined for XML files, not for HTML,
(though that might have changed) so a different rendering path could be
taken depending on the content type, if the HTML parser is optimized for
ASAP rendering, for instance.

> 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?
>
>
> We haven't measured this quantity, but these uses of XSLT won't be
> disrupted if we removed XSLT support from Blink.
Allright, so, whether or not it is more often used in other software
doesn't really matter then.

I make this point again, to show that this 'reason', or this 'benefit',
which is part of the argument, is of no consequence.
We might aswell say, that removing Javascript alltogether isn't so bad,
because it doesn't affect the weather.

> Are they significantly more than the statistics presented earlier?
> Also, why is this relevant?
>
>
> I included this information to make sure that folks understood that
> server-side use of XSLT won't be affected by this change.
I see. I'm guessing that people who would be confused about that
wouldn't even know what XSLT is. ;-)

>
> Motivation
>
> There are three motivations for removing XSLT support in Blink:
>
[..]
>
> 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).
>
>
> Memory usage is a complex topic. Binary size doesn't correlate
> directly to RAM usage, although the two are related.
Shouldn't be complex for a programmer. And I'd be more concerned with
RAM usage than with diskspace anyway,
given that the latter is several orders of magnitude larger.

> The binary savings from dropping libxslt is valuable.
Let's see. Saving 500kb, usually stored in a 4kb sector, on a terabyte
disk, costing 100$, would save
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'.

> 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.
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
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).

I'm merely pointing out that saving 500kb is not a good reason at all to
drop XSLT support, and it comes across to me
as if there weren't enough good reasons to begin with, so, to make a
convincing case, a minimum number of 'advantages' had to be conjured up.

> 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.
>
>
> The short answer is because XML is more widely used that XSLT,
> regardless of motivation of its designers.
I have more to say on this below. The short response is that to cut
oranges because apples are more widely consumed,
is another nonsense reason.

[cut - link to header file; thanks]

> 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).
>
>
> How is this gradual?
>
>
> Unfortunately, the plan outlined in my email from July didn't work.
Perhaps because it makes no sense. Removing support alltogether, all at
once, is not gradual at all.
There's no way to mitigate such a risk gradually.

[..]
>
> 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.
>
>
> I haven't taken any offense. I understand that removing XSLT support
> will make some number of people unhappy.
Just know that I am not one of them, as I have not taken offense either,
as this is a prerequisite for unhappiness.

> Unfortunately, if we constrained ourselves to never making anyone
> unhappy, we'd have trouble building the best product that we can
> build. There's a balance to be struck, and we're still searching for
> that balance.
I fundamentally disagree with that. Why should anyone be unhappy for
another to be happy? This is impossible.
But, I understand that most people see it that way, that their gain is
another's loss; another impossibility.

I personally find Firefox a better product than Chrome. If Chrome is
removing features that other browsers support,
I don't see why I would ever call it a good product, let alone the best.

Is stripping functionality because your software is badly designed
really the best you can do?

I appreciate that you're all finding your place, and this is as it
should be. I'm just posing a little challenge here,
offering some thoughts. If you're still searching, perhaps there's other
avenues besides the one that you propose.

> 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.
>
>
> My personal view is that XML on the client is going to evolve over the
> coming years. I expect that browsers will move to a simplified
> version of XML that doesn't support namespaces or internal DTD subsets
> because those features introduce vastly more complexity than they're
> worth. Instead, I expect we'll process XML content using the "foreign
> content" HTML parsing algorithm, which, for example, is how we parse
> SVG content in HTML.
Sounds like namespaces to me. They're pretty vital. DTD's, well, that
was a mistake to begin with ;-)

> 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.
>
>
> Generally speaking, I share your observations, but rather than using
> XSLT to process data on the client, I expect most developers will use
> JavaScript.
That's like comparing apples and oranges. Dynamic pages will always use
Javascript, and whether they employ XSLT
or not, is a different matter. But I suppose you're referring to
modifying the DOM.

> 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?
>
>
> Yes, I've done all of those things.
So you see how many developers are actually using it. And you can get an
idea about how many internet companies are then making sites using it.

> Another interesting source of data is language usage on GitHub:
>
> http://adambard.com/blog/top-github-languages-for-2013-so-far/
>
> That data says that JavaScript is >500x as popular as XSLT.
Not sure I trust that. It uses a "group by", and only attributes a
single language to a repository.
Generally XSLT is used together with files in other languages.
Btw, 264131/496<500.

It also says that Javascript is more popular than CSS, but I don't think
that's a reason to drop CSS support.
And HTML is nowhere to be found, I wonder what you make of that.

You know, my first message was quite fun to write, but this one is tedious.
I have absolutely no interest in a popularity contest,
nor of convincing you of anything.

The approach of statistics sounds like something sales managers would
do, people slaving away over money,
and has nothing whatsoever to do with the spirit of creating great
software, nor relates in any way to progress
and improvement. Working with balances is an accountants job, and this
decision seems to be based on money,
rather than building great software.
I can understand that, but that also means that if this is the mentality
behind Chrome, that it can never compete
with open source browsers.

In business, there are two ways to approach things. One way is to nibble
at the bottom, searching for scraps, saving on cost, which is what this
proposal is.
The other way is to expand at the top, to increase profit, to grow and
innovate.
I can't for the life of me reconcile this inane discussion to do away
with a well established web standard because it is badly implemented,
with all that the company that stands behind it has been, and is doing.

Thanks very much for your kind response. If you indeed go by the
numbers, don't care about innovation,
and apply the corporate democracy of greed, where majority rules and the
minority gets the boot,
then you're definitely on the right path with this proposal.

The funny thing is, I don't really care that much, but to me it seems
like a big mistake, and I wanted it said.
I'm all done now. Thanks for listening!

Kenney.

William Chan (陈智昌)

unread,
Dec 30, 2013, 11:53:32 PM12/30/13
to Kenney, Adam Barth, blink-dev
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/ezDvwXkBu5c/ejmgUtoLJGsJ
has some of the historical reasons why we care about binary size (lots
of it has to do with downloads, especially in regions with poor
bandwidth/connectivity). You can see that we've even created task
forces to tackle this problem. And the problem has only gotten worse
with Chromium on Android, since delays from paging in more code can
noticeably affect startup time, which is a major area of engineering
focus.

Cheers.

William Chan (陈智昌)

unread,
Dec 31, 2013, 12:05:56 AM12/31/13
to Kenney, Adam Barth, blink-dev
Another link: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/jblTeRKe7sk
- We need to switch to a new toolchain because it takes too much
memory to link chrome since there's too much code to link =/ Here's
another link about it:
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/2FnvtatJkds/GAZqLiIvjM0J.
Here's a /. discussion about Firefox having similar issues:
http://developers.slashdot.org/story/11/12/14/1725205/firefox-too-big-to-link-on-32-bit-windows.
There are also developer productivity and continuous builder issues
due to the large code size.

Code size does matter. It's not free.

eri...@teamworkgroup.com

unread,
Dec 31, 2013, 12:24:58 AM12/31/13
to blin...@chromium.org
The product I have been working on has been making fairly heavy use of XSLT, to the point of simulating xsl:include (don't think any browser does this properly) and xsl:namespace-alias (at least three different browser behaviors).  While I am sad to see the discussion about XSLT being deprecated, I do understand the reasons and arguments being made in favor of dropping support.  I have also noticed that IE has with version 10 deprecated use of XPath (finally acknowledging it and giving magic-word workarounds several months after people noticed).

I have spent a few hours googling all the proposed replacement libraries mentioned in this thread (and other libraries mentioned by those libraries) and I'm not really seeing any that go beyond the "Classic ASP-like" (or PHP-like) mixture of JavaScript and HTML, nor having the kind of power that XSLT has.  One thing I have liked from the approach of using XSLT is that you can do MVP separation, so replacing the template you use can completely change the look and feel of the page without (significant) JavaScript involvement.

The XSLT engine has permitted us to create rather complex templates based on very little (compressed) information going over the wire; The HTML that is eventually displayed in our app is a few tens of MB once it emerges from the transformations.  It's possible that a lot of this discussion has grown out of the improvements to the JavaScript engine; on IE I know an accidental use of jQuery .on() without a delegate in the wrong area can cause the browser to go non-responsive for a few seconds as it iterates through the DOM tree.  Chrome is of course several magnitudes faster.

There are a lot of aspects I don't currently like about XSLT.  It's reliance on XML as both the stylesheet declaration and data input is extremely wordy, to the point that our server-side logic will switch between XML and JSON output depending on whether the browser is intending to pass it to JavaScript or to the XSLT processor.  I'd absolutely love to switch to something with a much cleaner (and smaller) language.

I don't feel it a smart use of my time to spend time writing my own JavaScript-based templating engine that has the kind of power I've been using (and keep it the heck away from IE), and use of polyfill libraries to emulate what appears to be a dead language seems like a counterproductive means to slow down our app and reduce the benefit of client-side processing in the first place.

Am I missing something here?  Are there better templating libraries out there that I'm not seeing?  Other than the approach Moustache has taken for instance?  If I must write my own templating library, at least I've found a github project with a JavaScript-based XPath emulator.

Adam Barth

unread,
Dec 31, 2013, 2:19:09 AM12/31/13
to eri...@teamworkgroup.com, blink-dev
Here's a website that might help you choose among a number of popular template libraries:


Adam

smo...@gmail.com

unread,
Dec 31, 2013, 7:07:56 AM12/31/13
to blin...@chromium.org, eri...@teamworkgroup.com
This discussion is hopeless... We are getting nowhere. 
 

olive...@gmail.com

unread,
Dec 31, 2013, 7:17:48 AM12/31/13
to blin...@chromium.org
Thank you Kenney for summarizing why the discussion in this thread is so frustrating...

Daniel Bratell

unread,
Jan 2, 2014, 10:36:33 AM1/2/14
to Adam Barth, Kenney, blink-dev
On Tue, 31 Dec 2013 05:23:00 +0100, Kenney <ken...@gmail.com> wrote:

> 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
> 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).
>
> I'm merely pointing out that saving 500kb is not a good reason at all to
> drop XSLT support, and it comes across to me
> as if there weren't enough good reasons to begin with, so, to make a
> convincing case, a minimum number of 'advantages' had to be conjured up.

500 KB is actually quite a lot for such a feature regardless of how you
measure (coming from Opera/Presto I know our XML Parser/XPath/XSLT engine
is *much* smaller but unfortunately it's not portable to Chromium). So
when trying to shave some fat off the beast you look for features where
the cost is disproportionate to the gain.

We know that the gain of XSLT is much smaller than for instance HTML
Entities or GIF support, still it needs much more space. That is a major
reason why there is a discussion about what to do with it. Is it worth it?
Can it be made smaller? Can it be made optional? Should it be dropped? And
so on.

My personal opinion is that it's important for any browser to stay
compatible with the web as much as possible, but I also agree that it's a
costly feature in Chromium and I would like to see it shrink. Not all
computers running Chromium has a lot of RAM or disk, and some environments
constantly hit hardware limits.

(There also seems to be code maintenance issues but I'm not familiar
enough without those to comment on them.)

/Daniel

Torne (Richard Coles)

unread,
Jan 2, 2014, 10:58:39 AM1/2/14
to Kenney, Adam Barth, blink-dev
On 31 December 2013 04:23, Kenney <ken...@gmail.com> wrote:
The binary savings from dropping libxslt is valuable.
Let's see. Saving 500kb, usually stored in a 4kb sector, on a terabyte disk, costing 100$, would save
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.
 


    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.
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
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.

Peter Kroon

unread,
Jan 2, 2014, 12:00:37 PM1/2/14
to Torne (Richard Coles), Kenney, Adam Barth, blink-dev
What about disabling a view features by default in Chrome(mobile?).
You can enable them by using a script tag on your page.

<script type="text/enable-blink-internals">
  ENABLE_XSLT
  ENABLE_SVG
  ENABLE_MATHML
  ENABLE_ECMASCRIPT
  ENABLE_WEBAUDIO
</script>


2014/1/2 Torne (Richard Coles) <to...@chromium.org>

Dominic Mazzoni

unread,
Jan 2, 2014, 12:06:54 PM1/2/14
to Torne (Richard Coles), Kenney, Adam Barth, blink-dev
On Thu, Jan 2, 2014 at 7:58 AM, Torne (Richard Coles) <to...@chromium.org> wrote:

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.

Chrome didn't increase by 154 Mb. I suspect that you're comparing an install that Chrome was in the middle of auto-upgrading, so it had both the previous and new version installed at once. Peek inside the directory of Chrome 31, you'll probably see subdirectories for two different versions.

Kenney

unread,
Jan 2, 2014, 12:21:14 PM1/2/14
to Dominic Mazzoni, Torne (Richard Coles), Adam Barth, blink-dev
You're right, my bad:
$ 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
(Not sure when it'll clean it up though, I clicked 'upgrade' and when it was done, 'restart', a few days ago..._

The actual size of v31 is 138M, so the increase from v30 is 13Mb.

Kenney

unread,
Jan 2, 2014, 12:44:43 PM1/2/14
to Daniel Bratell, Adam Barth, blink-dev
Hi Daniel,

On 2-1-2014 16:36, Daniel Bratell wrote:
> On Tue, 31 Dec 2013 05:23:00 +0100, Kenney <ken...@gmail.com> wrote:
>
>> 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
>> 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).
>>
>> I'm merely pointing out that saving 500kb is not a good reason at all
>> to drop XSLT support, and it comes across to me
>> as if there weren't enough good reasons to begin with, so, to make a
>> convincing case, a minimum number of 'advantages' had to be conjured up.
>
> 500 KB is actually quite a lot for such a feature regardless of how
> you measure (coming from Opera/Presto I know our XML Parser/XPath/XSLT
> engine is *much* smaller but unfortunately it's not portable to
> Chromium). So when trying to shave some fat off the beast you look for
> features where the cost is disproportionate to the gain.
Yes, that makes sense. Btw, libxslt.dll is only 154kb - is the rest of
the 500kb the code that uses it?

> We know that the gain of XSLT is much smaller than for instance HTML
> Entities or GIF support, still it needs much more space. That is a
> major reason why there is a discussion about what to do with it. Is it
> worth it? Can it be made smaller? Can it be made optional? Should it
> be dropped? And so on.
>
> My personal opinion is that it's important for any browser to stay
> compatible with the web as much as possible, but I also agree that
> it's a costly feature in Chromium and I would like to see it shrink.
> Not all computers running Chromium has a lot of RAM or disk, and some
> environments constantly hit hardware limits.
I understand.
You'd probably want the browser to be able to compete both on desktop
and mobile markets, but, they have very different limitations.
If decisions are made to strip functionality because it means a
significant improvement on the mobile platform, then you'd generally
lose some marketshare in the desktop market,
and you'd basically end up with a product targeted for mobile, that's
less competent than it's desktop contemporaries. Or so I imagine. ;-)

Well, since libxslt is a dll, it's suitable for loading on demand. It
can be stored gzipped, in which case it only takes 77kb
diskspace (download and installed size), and, if loaded, the 154kb I
mentioned earlier plus temporary runtime memory.

If I start chrome (single tab, builtin page), be it on a 64 or 32
Windows 7 machine, I get figures like these:

PID NAME WorkingSet Memory(private) Commit Size
8212 chrome.exe *32 79.464k 57.808k 93.888k
8606 chrome.exe *32 68.936k 41.924k 76.260k
10976 chrome.exe *32 25.180k 13.824k 26.344k
12932 chrome.exe *32 72.988k 48.472k 59.508k
------------------------------------------------------------------------------+
246.586k 162.028k 256.000k

I agree that this is too much; a 500kb savings amounts to about 0.2%,
and, for me personally,
isn't worth losing XSLT over..

> (There also seems to be code maintenance issues but I'm not familiar
> enough without those to comment on them.)
Me neither; and, I do understand that reasons accumulate, but, all of
them should be sound, and preferrably capable of standing on their own.

>
> /Daniel

Thanks,
Kenney

Kenney

unread,
Jan 2, 2014, 2:44:35 PM1/2/14
to Torne (Richard Coles), Adam Barth, blink-dev
Hello,


On 2-1-2014 16:58, Torne (Richard Coles) wrote:
On 31 December 2013 04:23, Kenney <ken...@gmail.com> wrote:
The binary savings from dropping libxslt is valuable.
Let's see. Saving 500kb, usually stored in a 4kb sector, on a terabyte disk, costing 100$, would save
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.
I don't really see a difference between download size and disk usage, except that generally the files downloaded
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).


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.
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
that can be done, but it would lose some of it's desktop market share.


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.
(as pointed out by Dominic Mazzoni, this is incorrect:
The actual size of v31 is 138M, so the increase from v30 is 13Mb (or 26x XSLT ;-)
).


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.
Certainly. First, download size:
$ 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 don't really need all those. A tar.gz of this is 5.4 Mb download-size savings.

$ du -hcs d3dcompiler*
2.1M    d3dcompiler_43.dll
3.1M    d3dcompiler_46.dll
5.1M    total
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?)

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?



    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.
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
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.
Thank for you making my point for me ;-)

(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.

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.
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 ;-)


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.
Totally agree - less is more. I can fit an entire operating system in under 500kb, using the proper language ;-)

Thanks!
  Kenney

Victor Costan

unread,
Jan 2, 2014, 4:14:52 PM1/2/14
to Kenney, Torne (Richard Coles), Adam Barth, blink-dev
On Thu, Jan 2, 2014 at 2:44 PM, Kenney <ken...@gmail.com> wrote:
> 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.

I disagree with your assertion that Web developers would love having
XSLT as much as the Dev Tools (the console).

Many client-side frameworks use a variety of templating mechanisms.
Browsers should not pick a favorite, and instead should focus on
providing a robust foundation for all mechanisms / languages, so
developers can be free to use whatever they want. The demo apps
written using Angular.js and Ember.js demonstrate that the JavaScript
engines in pretty much all modern browsers can handle the templating
with acceptable performance characteristics. So it actually makes very
little sense to rely on a piece of code that you can't control for
your templating.

Dev Tools expose browser internals which cannot be accessed using
standardized Web platform features, and the information they provide
is useful to most developers, regardless of what they choose to use in
their technology stack. Also, FWIW, most of the Dev Tools
implementation is done in HTML / CSS / JavaScript, which is a lot
easier to maintain and secure than C++ code is.
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/devtools/front_end/

As a Web developer, I want the Blink team to focus on providing a
solid foundation for me to build my applications on. I also want the
Web platform to move forward, and for that to happen, we must be able
to abandon the ideas that didn't gain traction.

For your case, I think it would be more productive to contribute to a
JavaScript based XSLT engine. This would give you the guarantee that
your XSLTs are processed in the same way in all the browsers. As for
performance... if V8 can run the Unreal Engine, it can probably run an
XSLT engine :)

Victor

Kenney

unread,
Jan 2, 2014, 5:15:57 PM1/2/14
to Victor Costan, blink-dev
On 2-1-2014 22:14, Victor Costan wrote:

[note: I removed thorne@/aba...@chromium.org from the CC, I presume
they're on the list anyway]

> On Thu, Jan 2, 2014 at 2:44 PM, Kenney <ken...@gmail.com> wrote:
>> 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.
> I disagree with your assertion that Web developers would love having
> XSLT as much as the Dev Tools (the console).
Yeah, I didn't mean to say that; Rather, pretty much no-one uses xslt
besides webdevs. Is that better? :-)

> Many client-side frameworks use a variety of templating mechanisms.
> Browsers should not pick a favorite, and instead should focus on
> providing a robust foundation for all mechanisms / languages, so
> developers can be free to use whatever they want. The demo apps
> written using Angular.js and Ember.js demonstrate that the JavaScript
> engines in pretty much all modern browsers can handle the templating
> with acceptable performance characteristics. So it actually makes very
> little sense to rely on a piece of code that you can't control for
> your templating.
Maybe. If so, then I suppose XML and SGML should be removed from
browsers aswell.

The thing with XSLT is, that you can rely on it, because it is so
well-defined.
And, you can't control the piece of code that renders the HTML document.
IMHO it doesn't really matter whether you control the code, if it
follows the
specifications (besides political reasons such as licensing).

AFAIK browsers are built mainly to display HTML, which is SGML, and
XHTML, which is XML.
Javascript is something that came later (than HTML), and is an addon.
With such a view, a browser is starting to look more and more like a
Javascript runtime environment
and less like a web-page display system. That's fine of course, but if
you want to really go for it,
you'd probably want to write the entire browser in Javascript.

The idea was that <html> is the starting point, and "javascript" merely
the value of a <script> attribute;
the script language is pluggable, not the document format. But ofcourse,
it can be turned inside out
as you suggest. And it sure looks like it's heading in that direction.

> Dev Tools expose browser internals which cannot be accessed using
> standardized Web platform features,
Hm, well, if you count Javascript as a standardized web platform
feature, and dev tools are
written in Javascript, then I suppose you can, right?
> and the information they provide
> is useful to most developers, regardless of what they choose to use in
> their technology stack. Also, FWIW, most of the Dev Tools
> implementation is done in HTML / CSS / JavaScript, which is a lot
> easier to maintain and secure than C++ code is.
I beg to differ on that last line. But this is not a language flame-war
;-) The truth is, it does not matter.
With C++ for instance, you have strong typing and compile-time
correctness checking,
something that's completely absent in Javascript. And HTML/CSS have
nothing to do
with Javascript or C++ or any programming language.

> https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/devtools/front_end/
>
> As a Web developer, I want the Blink team to focus on providing a
> solid foundation for me to build my applications on.
As a web developer, you're aware that not everyone uses Chrome, which is
why there are Web standards (right?).
> I also want the
> Web platform to move forward, and for that to happen, we must be able
> to abandon the ideas that didn't gain traction.
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.

>
> For your case, I think it would be more productive to contribute to a
> JavaScript based XSLT engine. This would give you the guarantee that
> your XSLTs are processed in the same way in all the browsers.
Hm. ;-)
Well, XSLT is pretty well-defined, and there exist libraries that have
been in use for 10+ years,
very stable, bugs removed, and, execute natively, so, very fast (faster
than any scripted language
can be, by definition).

The problem is not libxslt, as that has been well tested and is used in
many programs. Replacing it
with a Javascript version won't solve any of the problems, as these are
due to browser integration,
something that would still need to be done.

> As for
> performance... if V8 can run the Unreal Engine, it can probably run an
> XSLT engine :)
Ah..(http://www.unrealengine.com/html5/)
OMG.

Ok. Forget I said anything ;-)

(i still stand by that native code is more efficient than a scripted
language though, and,
you can render those scenes using display lists, so all you'd need to do
is a handful of
calls per frame; the heavy lifting is done in hardware, not in
Javascript; but nevertheless
extremely impressive! (can't help myself ;-))

Awesome, Victor. Thanks very much! Perhaps writing the entire browser in
javascript
isn't so far fetched after all!

Well, I'm definitely starting to see the merit of having a Javascript
XSLTProcessor.
But, wouldn't Chrome want to bundle this, regardless, simply in order to
support <?xsl-stylesheet?>
such as used in RSS feeds and the like?

--
Kenney

PhistucK

unread,
Jan 2, 2014, 5:20:12 PM1/2/14
to Kenney, Torne (Richard Coles), Adam Barth, blink-dev
Comments inline.


PhistucK


On Thu, Jan 2, 2014 at 9:44 PM, Kenney <ken...@gmail.com> wrote:
Hello,


On 2-1-2014 16:58, Torne (Richard Coles) wrote:
On 31 December 2013 04:23, Kenney <ken...@gmail.com> wrote:
The binary savings from dropping libxslt is valuable.
Let's see. Saving 500kb, usually stored in a 4kb sector, on a terabyte disk, costing 100$, would save
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.
I don't really see a difference between download size and disk usage, except that generally the files downloaded
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).

​Download size matters because downloading takes time. A larger download takes more time.
Disk space (on desktop) is less of an issue, while download speeds within large ​parts of the world (or many mobile networks) are unusually low (compared to US speeds, for example), which makes download size a real issue.

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.

 


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.
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
that can be done, but it would lose some of it's desktop market share.


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.
(as pointed out by Dominic Mazzoni, this is incorrect:
The actual size of v31 is 138M, so the increase from v30 is 13Mb (or 26x XSLT ;-)

).

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.
Certainly. First, download size:
$ 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 don't really need all those. A tar.gz of this is 5.4 Mb download-size savings.

I somewhat agree, but keeping them there provides for better user experience when switching languages, I guess.
​​

$ du -hcs d3dcompiler*
2.1M    d3dcompiler_43.dll
3.1M    d3dcompiler_46.dll
5.1M    total
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?)

_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.

 

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.

​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).

 


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?



    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.
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
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.
Thank for you making my point for me ;-)

(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.

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.
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 ;-)

​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? ;)).

 


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.
Totally agree - less is more. I can fit an entire operating system in under 500kb, using the proper language ;-)

Thanks!
  Kenney

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Kenney

unread,
Jan 2, 2014, 7:20:16 PM1/2/14
to PhistucK, blink-dev
On 2-1-2014 23:20, PhistucK wrote:
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.
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?


[..]

$ 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 don't really need all those. A tar.gz of this is 5.4 Mb download-size savings.

I somewhat agree, but keeping them there provides for better user experience when switching languages, I guess.
Oh sure, it makes it possible to have 1 installer for the whole world.
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.



$ du -hcs d3dcompiler*
2.1M    d3dcompiler_43.dll
3.1M    d3dcompiler_46.dll
5.1M    total
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?)

_34 is irrelevant here, or else it would have been used (either bundled or not).​​
Typo, I meant _43.


Also, I guess not everyone has them.
They should, as they are part of DirectX. Chrome doesn't bundle all of DirectX AFAIK, so, it already relies on it being installed.




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.
Well, perhaps. But this is the eternal tradeoff, speed vs. size. And, it's the same mechanism that any operating system
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.



 

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.
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
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.

 [..]
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).
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).


[...]

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.
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 ;-)

​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? ;)).
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..
And no, I was just an early adopter ;-)

Thanks, interesting stuff!

Victor Costan

unread,
Jan 2, 2014, 7:28:58 PM1/2/14
to Kenney, blink-dev
On Thu, Jan 2, 2014 at 5:15 PM, Kenney <ken...@gmail.com> wrote:
> Maybe. If so, then I suppose XML and SGML should be removed from browsers
> aswell.
>
> The thing with XSLT is, that you can rely on it, because it is so
> well-defined.
> And, you can't control the piece of code that renders the HTML document.
> IMHO it doesn't really matter whether you control the code, if it follows
> the
> specifications (besides political reasons such as licensing).

I didn't mean "control" in a political sense. I meant "control" in the
sense that if there is a bug in my JavaScript, I can fix it, deploy a
new version on my site, and all my users will download and execute the
new JavaScript. If there is a bug in Blink / WebKit / Gecko / Trident,
I have no control over when my users will update their browsers.

Also, even if we assume a Chrome user with auto-update, if I commit a
fix to Blink today, it will land in Chrome 34, which is a few months
out. This is really fast for a browser (compare it to IE's cycle), but
is still a lot slower than the speed at which I can update the JS on
my site.

I envy you for thinking you can rely on a feature because it has been
specified! Your development life has been way smoother than mine :)
Here are a couple of gems that I found just this past week, by looking
to a couple of XML-related bugs.

Original bug: http://crbug.com/248044
New bugs: http://crbug.com/330949 http://crbug.com/330946

Sadly, complex specs bring high probabilities of implementation bugs.

> AFAIK browsers are built mainly to display HTML, which is SGML, and XHTML,
> which is XML.
> Javascript is something that came later (than HTML), and is an addon.
> With such a view, a browser is starting to look more and more like a
> Javascript runtime environment
> and less like a web-page display system. That's fine of course, but if you
> want to really go for it,
> you'd probably want to write the entire browser in Javascript.

There are many advantages to pushing as much as possible into
JavaScript. Here is an interesting read from some smart folks who
tried to see how far this can go.
http://research.microsoft.com/apps/pubs/default.aspx?id=154698

> Hm, well, if you count Javascript as a standardized web platform feature,
> and dev tools are
> written in Javascript, then I suppose you can, right?

I did say "most" of Dev Tools are JavaScript. There is a C++ component
that provides the information to the JavaScript.

Here is a bit more of the story. It blew my mind.
https://developers.google.com/chrome-developer-tools/docs/debugger-protocol
Also, here is the C++ code.
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/inspector/

It is a non-trivial amount of code, but nowhere near what you'd need
if the whole UI would be C++.

>> and the information they provide
>> is useful to most developers, regardless of what they choose to use in
>> their technology stack. Also, FWIW, most of the Dev Tools
>> implementation is done in HTML / CSS / JavaScript, which is a lot
>> easier to maintain and secure than C++ code is.
>
> I beg to differ on that last line. But this is not a language flame-war ;-)
> The truth is, it does not matter.
> With C++ for instance, you have strong typing and compile-time correctness
> checking,
> something that's completely absent in Javascript. And HTML/CSS have nothing
> to do
> with Javascript or C++ or any programming language.

I'm a lot more scared when I write C++ than when I write JavaScript.
These papers talk about some of the issues that I don't have to worry
about in JavaScript.
http://pdos.csail.mit.edu/papers/chen-kbugs.pdf
http://pdos.csail.mit.edu/papers/ub:apsys12.pdf

That being said, I agree that development speed is subjective and
depends on experience. On a more positive side, if you are more
productive in C++, you can use something like emscripten to write your
Web applications in C++. https://github.com/kripken/emscripten

The idea might sound horrible at first, but the truth is modern JS VMs
can recognize the statically typed code and optimize it pretty well,
as proven by benchmarks like Octane.

>> As a Web developer, I want the Blink team to focus on providing a
>> solid foundation for me to build my applications on.
>
> As a web developer, you're aware that not everyone uses Chrome, which is why
> there are Web standards (right?).

For sure. Standards are the only way to remain sane. Let me rephrase
the above -- I want the Blink/WebKit/Gecko/Trident teams to focus on
implementing Web standards as accurately as possible (no bugs), so I
can spend less time debugging and patching around browser issues, and
more time building new awesome features.

Removing some features means that other features get more engineering
power, which hopefully translates into fewer bugs and better perf.

> https://www.google.com/#q=xslt -> 3.7 million results.
> https://www.google.com/#q=javascript -> 0.89 million results.

My searches show 0.89 billion results for javascript. (880 million)

>> For your case, I think it would be more productive to contribute to a
>> JavaScript based XSLT engine. This would give you the guarantee that
>> your XSLTs are processed in the same way in all the browsers.
>
> Hm. ;-)
> Well, XSLT is pretty well-defined, and there exist libraries that have been
> in use for 10+ years,
> very stable, bugs removed, and, execute natively, so, very fast (faster than
> any scripted language
> can be, by definition).

I think "fast enough" is more important than "very fast", especially
on the desktop, where battery power is not an issue. If it is
impossible to write a fast enough XSLT processor in JavaScript, that
sounds like a bottleneck that the V8 folks should address.

> The problem is not libxslt, as that has been well tested and is used in many
> programs. Replacing it
> with a Javascript version won't solve any of the problems, as these are due
> to browser integration,
> something that would still need to be done.

Native browser support for XSLT can accumulate bugs in the integration
code too, if few people use it. Blink has an extensive set of tests,
but bugs still make it to the Beta and Release channels. The XML bugs
I mentioned above are a good example.

> (i still stand by that native code is more efficient than a scripted
> language though, and,
> you can render those scenes using display lists, so all you'd need to do is
> a handful of
> calls per frame; the heavy lifting is done in hardware, not in Javascript;
> but nevertheless
> extremely impressive! (can't help myself ;-))

I agree that native code will always be faster than JavaScript, but at
the same time we can't push everything into the browser. Real people
have to implement and maintain all this code :)

I also agree that such a demo can be deceiving, though I think that
you'd need to do at least collision detection and occlusion culling in
JavaScript... I'd be shocked if you can load the entire world on the
GPU.

Fortunately, there are other benchmarks that can help put together a
better picture of the current performance of JS engines.
http://kripken.github.io/lua.vm.js/lua.vm.js.html
https://developers.google.com/octane/benchmark
http://dromaeo.com/
http://www.webkit.org/perf/sunspider/sunspider.html

The benchmarks related to string operations seem the most relevant. I
think we can be grateful to the engineers behind V8,
WhateverMonkeyIsHotRightNow and JavaScriptCore. These things are
really fast nowadays!

> Well, I'm definitely starting to see the merit of having a Javascript
> XSLTProcessor.
> But, wouldn't Chrome want to bundle this, regardless, simply in order to
> support <?xsl-stylesheet?>
> such as used in RSS feeds and the like?

I don't know enough about the Blink codebase yet, but I don't think
there is any special support for RSS feeds.
https://code.google.com/p/chromium/codesearch#search/&q=RSS%20case:yes%20file:src/third_party/WebKit&p=1&sq=package:chromium&type=cs

Also, I'm reasonably sure that Chrome doesn't have any built-in
support for RSS feeds, and users have to get extensions for that.

Victor

Jeremy Roman

unread,
Jan 2, 2014, 9:11:23 PM1/2/14
to Kenney, Victor Costan, blink-dev
On Thu, Jan 2, 2014 at 5:15 PM, Kenney <ken...@gmail.com> wrote:
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.

Nope. It's 3.7 million to 0.89 billion (880 million). You're off by a factor of 1000.

(Not that this is really what's at issue here.)

eri...@teamworkgroup.com

unread,
Jan 3, 2014, 12:40:09 AM1/3/14
to blin...@chromium.org
If I wasn't using XSLT so heavily then I would likely be on the side of dropping it; the arguments here sound pretty good to me.  I know that in IE there are two different types of DOM nodes - the internal browser DOM (which support CSS queries and are returned by default by all AJAX queries) and their version of libxml nodes (which you now have to specifically ask for, which support XPath and XSLT).  The internal DOM nodes advertise XPath support, but any attempts to call them throw E_NOTIMPL (the last time I looked).

I haven't looked at Chrome source in years (and in very sparing amounts at that time).  Is the browser translating DOM trees to strings, moving it into libxml, doing the translation, then bringing it back into Chrome as a string?  If so then that likely explains some rather strange namespace behaviors I've been working around.  If that's what's happening here then this XSLT implementation is feeling a bit hackish to begin with and I can understand the want to cut the lines.

I would feel a lot more comfortable with this feature drop if it was more obvious there were polyfills out there that achieve parity with the current implementation.  I know of one Java-compiled implementation that I have not tried yet, although from the reports I read here there are some performance issues with it.

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),

Adam Barth

unread,
Jan 3, 2014, 1:13:39 AM1/3/14
to Erik Anderson, blink-dev
On Thu, Jan 2, 2014 at 9:40 PM, <eri...@teamworkgroup.com> wrote:
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),

I haven't heard anyone interested in removing XPath support.  I'm not sure we'd implement it today, but our existing implementation isn't much of a burden to maintain.

Adam

Peter Kroon

unread,
Jan 3, 2014, 6:12:14 AM1/3/14
to Adam Barth, Erik Anderson, blink-dev
I still think xslt support should not be dropped.
I think it should remain supported. Just because there are a ton of js/json templating systems doesn't mean that xslt should be dropped. As a mater of fact. I think those are screams for a non proper working/implementeation of the xslt lib in Chrome/Blink/WebKit.

xml+xslt+js xslt processor+xpath are much easier to use with far less code than the entire angular.js lib which is not easy to use(just like the other js templating systems) and has got a lot of additional code that i will never use. Just like jquery which I'm not using.

When converting the xslt lib to js would that mean that the lib would still be implemented in the browser like asm.js and pdf.js in firefox or like jquery as an external lib?

xslt+xml+js xslt proscessor+xpath should be BOOSTED and not be dropped.


2014/1/3 Adam Barth <aba...@chromium.org>

Kenney

unread,
Jan 3, 2014, 8:09:26 AM1/3/14
to Jeremy Roman, Victor Costan, blink-dev
Yeah... Silly me... must be blind! :-/
It's nice to see 'peer review' at work though!
Thanks (to Victor aswell)!

PhistucK

unread,
Jan 3, 2014, 9:12:46 AM1/3/14
to Kenney, blink-dev
Comments inline.


PhistucK


On Fri, Jan 3, 2014 at 2:20 AM, Kenney <ken...@gmail.com> wrote:
On 2-1-2014 23:20, PhistucK wrote:
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.
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?

I just meant that 500 kilobytes of a shared or a static library does not map to 500 KB of RAM/memory, due to whatever reasons, especially the last one (a program allocates memory).​​



[..]

$ 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 don't really need all those. A tar.gz of this is 5.4 Mb download-size savings.

I somewhat agree, but keeping them there provides for better user experience when switching languages, I guess.
Oh sure, it makes it possible to have 1 installer for the whole world.
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 ;-)

​These DLLs generally contain lots of strings. Strings tend to compress pretty well, while good old binary code ​does not generally compress well.
Still, I think your point is valid. I never understood the reason but bundling all of the languages.
However, these do not affect memory usage (which is the important feature here, other than the aforementioned wasteful download size), since Chrome loads just one of these and never more than one.
 

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.



$ du -hcs d3dcompiler*
2.1M    d3dcompiler_43.dll
3.1M    d3dcompiler_46.dll
5.1M    total
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?)

_34 is irrelevant here, or else it would have been used (either bundled or not).​​
Typo, I meant _43.

I would assume there is a real need for _46 then, the team does not tend to include such large binaries for no reason.​ But you can start a debate regarding this, it might yield some good reasons, or some nice savings.

 

Also, I guess not everyone has them.
They should, as they are part of DirectX. Chrome doesn't bundle all of DirectX AFAIK, so, it already relies on it being installed.

I am not familiar with DirectX or the way to work with it, so I cannot provide accurate or backed comments here. I do not know whether you need the entire DirectX framework (or whatever it is called) in order to run those DLLs, or implement hardware acceleration. In case you do not need the entire DirectX framework, that might be the reason. I think Windows Vista and later ​embed DirectX, however I think Windows XP (which is a very large audience of Chrome) does not, so maybe in order not to depend on the full DirectX framework, Chrome bundles the needed DLLs and is done with it this way. Chrome has a single Windows installer (more or less), so it contains everything it may need for all of the platforms (XP to 8.1) it supports.

 



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.
Well, perhaps. But this is the eternal tradeoff, speed vs. size. And, it's the same mechanism that any operating system
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.

​Yep, the disk related speed is the overhead to which I was referring.​ Also, a single (or as few as possible) DLL can be optimized further by the compiler, I believe.

 
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.

​The edition of Chrome that is meant for developing and debugging actually has separate DLLs for various components (hence the name "component build" or something). So while the finished product has a single (or dual) DLL for Chrome itself, there is an API (albeit not a stable one) for all of the components that are supported as separate DLLs for debugging.

 


 

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.
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
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.

 [..]
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).
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).

​Pentium 4 implies a single core machine. While these are supported, I would not count them as good examples. Dual (or more) core machine exist (as a 'standard' machine) for more than seven years now, I believe. 1.5 GB is also pretty low for a few years now, I believe.
Take an old and slow machine and your responsiveness would decrease, no doubt about that.


 


[...]
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.
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 ;-)

​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? ;)).
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..
And no, I was just an early adopter ;-)

​64 GB was not the standard and it had (and has) a much higher price tag. Not everyone is willing to pay so much and some vendors probably figured that and stopped coming up with such editions.

 

Thanks, interesting stuff!



One more thing about which I have been meaning to comment​ was that I believe the team mentioned that if someone wants to develop an XSLT engine for Blink that integrates better, with less bloat and complication, that might get accepted (discuss the design first, get a green light from the team and develop).
The team apparently has no interest in developing such an engine, but if you (or others) feel strongly about it and can spare some of your time in order to help progress XSLT within Blink in a way that surely outperforms the complications and performance of the current one, there is a chance they would accept it.
​It is a matter of interest, after all. Like Firefox (or others) does not implement some CSS (or other technologies) specifications that others do, even though they are useful and used by developers.​ I do not have an example, but I think it is pretty clear even without one.

​I am not saying the public must be burdened with developing for Google (I know it sounds ridiculous), but everyone has their interests and if there are enough people that want to keep using Chrome, that are willing and has the ability to put such an effort in it, they probably can.​

Torne (Richard Coles)

unread,
Jan 3, 2014, 9:41:53 AM1/3/14
to Kenney, PhistucK, blink-dev
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).
 
But, maybe the term means someting else here?


[..]

$ 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 don't really need all those. A tar.gz of this is 5.4 Mb download-size savings.

I somewhat agree, but keeping them there provides for better user experience when switching languages, I guess.
Oh sure, it makes it possible to have 1 installer for the whole world.
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).
 

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.



$ du -hcs d3dcompiler*
2.1M    d3dcompiler_43.dll
3.1M    d3dcompiler_46.dll
5.1M    total
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?)

_34 is irrelevant here, or else it would have been used (either bundled or not).​​
Typo, I meant _43.

Also, I guess not everyone has them.
They should, as they are part of DirectX. Chrome doesn't bundle all of DirectX AFAIK, so, it already relies on it being installed.

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.
 



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.
Well, perhaps. But this is the eternal tradeoff, speed vs. size. And, it's the same mechanism that any operating system
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).
 
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.

Defining clean API boundaries between things that aren't necessarily actually independent of each other in most cases makes development much more difficult, not easier. There's a reason why the Linux kernel developers don't maintain a stable kernel interface and instead just fix every driver when they feel like changing an interface, and we operate in much the same way: we have stable interfaces where they add value to our process, but we avoid them everywhere else.
 


 

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.
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
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.

 [..]
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).
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).

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.
 


[...]
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.
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 ;-)

​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? ;)).
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..
And no, I was just an early adopter ;-)

Thanks, interesting stuff!


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; 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 :)

Alf Eaton

unread,
Jan 3, 2014, 11:25:02 AM1/3/14
to blin...@chromium.org
To bring this example up to date: I ended up switching to using xslt2.js from <http://frameless.io/xslt/>. It's 60KB gzipped, and converts the test document in 200ms (5x slower than 40ms with the native XSLT processor, but still fast enough). 

On the down side, the API is slightly different (it loads the stylesheet asynchronously), and the license is only free for personal/non-commercial use.

For this use case, though, it works well enough that I'd be happy for native XSLT support to be removed.

Alf

On Friday, 26 July 2013 07:39:33 UTC+1, Alf Eaton wrote:
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.


Alf

On Monday, 22 July 2013 22:55:15 UTC+1, Adam Barth wrote:

Primary eng (and PM) emails

aba...@chromium.org


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.

Bruce Lawson

unread,
Jan 3, 2014, 12:01:11 PM1/3/14
to blin...@chromium.org


On Monday, 22 July 2013 22:55:15 UTC+1, Adam Barth wrote:

Primary eng (and PM) emails

aba...@chromium.org


[...]
 

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.

FWIW,   The Record of Proceedings  of the National Assembly of Wales uses XSLT http://www.assemblywales.org/docs/rop_xml/131211_plenary_bilingual.xml

Perhaps there is some CMS that government sites use? Might be worth checking that out, as breaking gvt sites wouldn't be good.

bruce lawson

Kenney

unread,
Jan 3, 2014, 3:34:26 PM1/3/14
to Victor Costan, blink-dev
Hi Victor,

Well, I agree with you on all counts. Nothing real to add, except to say
thank you for
the links, interesting reads indeed. You definitely got your stuff
together :-)

That said, some comments below.

On 3-1-2014 1:28, Victor Costan wrote:
> On Thu, Jan 2, 2014 at 5:15 PM, Kenney<ken...@gmail.com> wrote:
>> Maybe. If so, then I suppose XML and SGML should be removed from browsers
>> aswell.
>>
>> The thing with XSLT is, that you can rely on it, because it is so
>> well-defined.
>> And, you can't control the piece of code that renders the HTML document.
>> IMHO it doesn't really matter whether you control the code, if it follows
>> the specifications (besides political reasons such as licensing).
> I didn't mean "control" in a political sense. I meant "control" in the
> sense that if there is a bug in my JavaScript, I can fix it, deploy a
> new version on my site, and all my users will download and execute the
> new JavaScript. If there is a bug in Blink / WebKit / Gecko / Trident,
> I have no control over when my users will update their browsers.
>
> Also, even if we assume a Chrome user with auto-update, if I commit a
> fix to Blink today, it will land in Chrome 34, which is a few months
> out. This is really fast for a browser (compare it to IE's cycle), but
> is still a lot slower than the speed at which I can update the JS on
> my site.
Yes indeed. But who'd want to compare their product with IE? ;-)
I suppose it's all about striking the proper balance, because as far as
I can tell,
the browser will remain the foundation, and it will continue to have
bugs (I've never heard
of a bug-free program). A well known javascript library also has the
advantage of being
tested on multiple browsers, much like libxslt has been tested in a lot
of different programs ;-)

One thing, though. If i interpret what you said in the context of the
topic of deprecating XSLT,
then it might seem that users are unhappy about the speed at which such
bugs are fixed,
or that the chromium team can't fix bugs fast enough, and that users are
better off using their
own code. This may well be, and dropping support alltogether kind of
forces the issue.

That's why I'm really appreciative of all the suggestions made in
helping to find a replacement
for the functionality, and the time and effort put into getting me up to
speed and showing me
around. Thank you all.

> I envy you for thinking you can rely on a feature because it has been
> specified! Your development life has been way smoother than mine :)
Not really ;-) But it's nice to have a well defined standard to point to
and program against
that. In this particular case, both the specs and the implementation
came out of the garage
about the same time Google did.

> Here are a couple of gems that I found just this past week, by looking
> to a couple of XML-related bugs.
>
> Original bug:http://crbug.com/248044
> New bugs:http://crbug.com/330949 http://crbug.com/330946
>
> Sadly, complex specs bring high probabilities of implementation bugs.
Well, I have to give it to you, the w3c specs are not always an easy
read. But these bugs
are, IMHO, pretty silly if you consider that attribute names are
supposed to be unique, and that "<"
is a reserved character in XML. I wish all bugs were that easy to fix ;-)

>> AFAIK browsers are built mainly to display HTML, which is SGML, and XHTML,
>> which is XML.
>> Javascript is something that came later (than HTML), and is an addon.
>> With such a view, a browser is starting to look more and more like a
>> Javascript runtime environment
>> and less like a web-page display system. That's fine of course, but if you
>> want to really go for it,
>> you'd probably want to write the entire browser in Javascript.
> There are many advantages to pushing as much as possible into
> JavaScript. Here is an interesting read from some smart folks who
> tried to see how far this can go.
> http://research.microsoft.com/apps/pubs/default.aspx?id=154698
>
>> Hm, well, if you count Javascript as a standardized web platform feature,
>> and dev tools are
>> written in Javascript, then I suppose you can, right?
> I did say "most" of Dev Tools are JavaScript. There is a C++ component
> that provides the information to the JavaScript.
Ofcourse. The browser must provide access points, obviously.

> Here is a bit more of the story. It blew my mind.
> https://developers.google.com/chrome-developer-tools/docs/debugger-protocol
Pretty neat. It Javascript is definitely becoming mature. (can't judge a
language without it's best IDE, now can we).


> Also, here is the C++ code.
> https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/inspector/
>
> It is a non-trivial amount of code, but nowhere near what you'd need
> if the whole UI would be C++.
>
>>> and the information they provide
>>> is useful to most developers, regardless of what they choose to use in
>>> their technology stack. Also, FWIW, most of the Dev Tools
>>> implementation is done in HTML / CSS / JavaScript, which is a lot
>>> easier to maintain and secure than C++ code is.
>> I beg to differ on that last line. But this is not a language flame-war ;-)
>> The truth is, it does not matter.
>> With C++ for instance, you have strong typing and compile-time correctness
>> checking,
>> something that's completely absent in Javascript. And HTML/CSS have nothing
>> to do
>> with Javascript or C++ or any programming language.
> I'm a lot more scared when I write C++ than when I write JavaScript.
> These papers talk about some of the issues that I don't have to worry
> about in JavaScript.
> http://pdos.csail.mit.edu/papers/chen-kbugs.pdf
> http://pdos.csail.mit.edu/papers/ub:apsys12.pdf
Oh that's just awful, isn't it?
However, javascript code itself is not really much concerned with
permissions (usually languages
having an 'eval' aren't) - but I may be mistaken here!
And, that second paper pretty much only deals with compiler
optimisation, which has in fact little
to do with the programming language used. I suppose if you use
emscripten you'd have the same
issues (same LLVM backend AFAIK).

> That being said, I agree that development speed is subjective and
> depends on experience. On a more positive side, if you are more
> productive in C++, you can use something like emscripten to write your
> Web applications in C++.https://github.com/kripken/emscripten
Or Java! ;-)
> The idea might sound horrible at first, but the truth is modern JS VMs
> can recognize the statically typed code and optimize it pretty well,
> as proven by benchmarks like Octane.
Yes, it does seem pretty fast, though it's hard to tell how efficient it
is without comparing them
with native algorithms too, although in V8 that seems rather pointless
as you'd have all the
speed of native compilers, and 'hotspot' optimisation aswell.

>>> As a Web developer, I want the Blink team to focus on providing a
>>> solid foundation for me to build my applications on.
>> As a web developer, you're aware that not everyone uses Chrome, which is why
>> there are Web standards (right?).
> For sure. Standards are the only way to remain sane. Let me rephrase
> the above -- I want the Blink/WebKit/Gecko/Trident teams to focus on
> implementing Web standards as accurately as possible (no bugs), so I
> can spend less time debugging and patching around browser issues, and
> more time building new awesome features.
Couldn't agree more. Things have definitely improved since the early
days when you almost
couldn't get a webpage to look the same in two different browsers.


> Removing some features means that other features get more engineering
> power, which hopefully translates into fewer bugs and better perf.
>> https://www.google.com/#q=xslt -> 3.7 million results.
>> https://www.google.com/#q=javascript -> 0.89 million results.
> My searches show 0.89 billion results for javascript. (880 million)
Temporary blindness. ;-)

>>> For your case, I think it would be more productive to contribute to a
>>> JavaScript based XSLT engine. This would give you the guarantee that
>>> your XSLTs are processed in the same way in all the browsers.
>> Hm. ;-)
>> Well, XSLT is pretty well-defined, and there exist libraries that have been
>> in use for 10+ years,
>> very stable, bugs removed, and, execute natively, so, very fast (faster than
>> any scripted language
>> can be, by definition).
> I think "fast enough" is more important than "very fast", especially
> on the desktop, where battery power is not an issue. If it is
> impossible to write a fast enough XSLT processor in JavaScript, that
> sounds like a bottleneck that the V8 folks should address.
Right. Pushing the libxslt source through emscripten, then running it in V8,
and you'd end up with pretty much the exact same thing we have now, except,
as I understand it, it'd make Chrome a lot easier to maintain.

>> The problem is not libxslt, as that has been well tested and is used in many
>> programs. Replacing it
>> with a Javascript version won't solve any of the problems, as these are due
>> to browser integration,
>> something that would still need to be done.
> Native browser support for XSLT can accumulate bugs in the integration
> code too, if few people use it. Blink has an extensive set of tests,
> but bugs still make it to the Beta and Release channels. The XML bugs
> I mentioned above are a good example.
>
>> (i still stand by that native code is more efficient than a scripted
>> language though, and,
>> you can render those scenes using display lists, so all you'd need to do is
>> a handful of
>> calls per frame; the heavy lifting is done in hardware, not in Javascript;
>> but nevertheless
>> extremely impressive! (can't help myself ;-))
> I agree that native code will always be faster than JavaScript, but at
> the same time we can't push everything into the browser. Real people
> have to implement and maintain all this code :)
No, I get that. As for people being real... ;-)
> I also agree that such a demo can be deceiving, though I think that
> you'd need to do at least collision detection and occlusion culling in
> JavaScript... I'd be shocked if you can load the entire world on the
> GPU.
Well, be shocked, because that's how it's done. In the end, the entire
world must pass
through the GPU for it to be rendered, after all. In practice, all you
need to do is iterate
through the objects of the scene, and for each, configure the texture
units and call a
display list.
I didn't see much collision detection in the benchmark. And occlusion
culling is surprisingly
well handled by the GPU. I once wrote a Quake3 map renderer in C++
implementing btrees,
occlusion culling and what have you, and then I implemented it in Java
without these (rendering
the entire map), and it actually ran faster.

> Fortunately, there are other benchmarks that can help put together a
> better picture of the current performance of JS engines.
> http://kripken.github.io/lua.vm.js/lua.vm.js.html
> https://developers.google.com/octane/benchmark
> http://dromaeo.com/
> http://www.webkit.org/perf/sunspider/sunspider.html
>
> The benchmarks related to string operations seem the most relevant. I
> think we can be grateful to the engineers behind V8,
> WhateverMonkeyIsHotRightNow and JavaScriptCore. These things are
> really fast nowadays!
Yes they are. It's coming of age.

>> Well, I'm definitely starting to see the merit of having a Javascript
>> XSLTProcessor.
>> But, wouldn't Chrome want to bundle this, regardless, simply in order to
>> support <?xsl-stylesheet?>
>> such as used in RSS feeds and the like?
> I don't know enough about the Blink codebase yet, but I don't think
> there is any special support for RSS feeds.
> https://code.google.com/p/chromium/codesearch#search/&q=RSS%20case:yes%20file:src/third_party/WebKit&p=1&sq=package:chromium&type=cs
>
> Also, I'm reasonably sure that Chrome doesn't have any built-in
> support for RSS feeds, and users have to get extensions for that.
>
> Victor
And <?xsl-stylsheet?> is not used much on the client side, after all.

Thanks a lot!
Kenney


Kenney

unread,
Jan 3, 2014, 3:35:21 PM1/3/14
to Torne (Richard Coles), blink-dev
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:
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.
Well, someone had to have implemented it, and it is really all pretty well defined. It's not black magic.
See, for example: http://en.wikipedia.org/wiki/Executable_and_Linkable_Format#Specifications


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.
I don't see how this is any different from what I said, in response to 'incorrect/irrelevant', above.

But thank you for clarifying!


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).
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?)


$ 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 don't really need all those. A tar.gz of this is 5.4 Mb download-size savings.

I somewhat agree, but keeping them there provides for better user experience when switching languages, I guess.
Oh sure, it makes it possible to have 1 installer for the whole world.
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).
Now you're contradicting yourself:

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
So I gather that the most important aspect of 'binary size' means the runtime memory footprint, then, something that I completely agree with.
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.
[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
defending a reason for doing something when you don't know that reason is hardly a sound argument.





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.
Well, perhaps. But this is the eternal tradeoff, speed vs. size. And, it's the same mechanism that any operating system
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:
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.


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).
That depends on the linker you use. If a function pointer table is employed, then yes. But don't forget that all accesses
to those table entries are present in the relocation table, and the loader could write the values there directly, aswell.


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 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.
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.


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;
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.

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.
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.
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.


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).
Is it now. They're both the same concept.
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.



[..]

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).
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).

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).
Can you show me where I am confused about that?


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.
Yes! Sounds like all that is well covered!

[]


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)
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.
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.


and are overlooking the bigger picture :)
Yes indeed :-)
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

Torne (Richard Coles)

unread,
Jan 6, 2014, 9:32:28 AM1/6/14
to Kenney, blink-dev
On 3 January 2014 20:35, Kenney <ken...@gmail.com> wrote:
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.

I've added a few more comments but this isn't really going anywhere as you are just asserting that I'm wrong while repeating the same incorrect statements, so I'm not going to reply after this, sorry. :/
 

On 3-1-2014 15:41, Torne (Richard Coles) wrote:
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.
Well, someone had to have implemented it, and it is really all pretty well defined. It's not black magic.
See, for example: http://en.wikipedia.org/wiki/Executable_and_Linkable_Format#Specifications

The ELF spec is not sufficient to actually understand how binaries are loaded in memory. We support a bunch of platforms with different binary formats (ELF, Mach-O, Portable EXE), we support more than one different architecture with different ABIs that affect the binary format and loader (x86, amd64, arm, mips), and even that isn't the whole story, since a lot of the behaviour is determined by the runtime behaviour of the dynamic loader (e.g. are symbols resolved eagerly or lazily, which is not always determined by the binary format) and also by the runtime behaviour of the kernel.

Trust me, I wish it was as simple as you think it is, as it'd make my life significantly easier, but actually it *is* much more like black magic, and I say this as someone who's implemented paging/loading/etc in kernels before :)
 

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.
I don't see how this is any different from what I said, in response to 'incorrect/irrelevant', above.

But thank you for clarifying!


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).
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?)


$ 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 don't really need all those. A tar.gz of this is 5.4 Mb download-size savings.

I somewhat agree, but keeping them there provides for better user experience when switching languages, I guess.
Oh sure, it makes it possible to have 1 installer for the whole world.
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).
Now you're contradicting yourself:

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
So I gather that the most important aspect of 'binary size' means the runtime memory footprint, then, something that I completely agree with.
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.

Except that this increases the overall size, as I explained, and also makes things slower, and also makes the code more complex and difficult to maintain (since this would then need to be maintained as a component with a semistable interface).
[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
defending a reason for doing something when you don't know that reason is hardly a sound argument.

It *is* unlikely that we're bundling several copies of a library for no reason. It's not impossible, but it's a kind of mistake that would be noticed :)
 



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.
Well, perhaps. But this is the eternal tradeoff, speed vs. size. And, it's the same mechanism that any operating system
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:
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.

Except as I explained this does *not* provide a size benefit in most cases. It's *not* the same mechanism as paging at all.
 
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).
That depends on the linker you use. If a function pointer table is employed, then yes. But don't forget that all accesses
to those table entries are present in the relocation table, and the loader could write the values there directly, aswell.

We are not inventing our own linker or our own ABI; we behave in the standard way for the platform we're running on (which is different for each of the platforms we support). ELF-based systems use position independant code for shared libraries, which means that there *aren't* relocations for each individual call and it's *not* possible to have the loader fix up the calls directly, there is always an indirection via the relocated dynamic symbols. DLL-based systems use export/import tables and similarly always have an indirection. Patching callsites directly is slow and expensive (both in disk IO and in RAM usge, since this makes a lot of pages dirty) and no modern dynamic loader on a mainstream platform works this way that I'm aware of.
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 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.
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.

No, sorry, you are just wrong. Splitting code into more libraries is very likely to increase the total memory usage; relocation tables do not work the way you think. The references in a single library are coalesced into a single location (the indirection referred to in the previous section), but references across multiple libraries can't be coalesced, so having more libraries means you have more relocations that refer to the same symbols, taking up more space.

It's not difficult to test this for yourself: write a program that consists of three libraries, A, B and C, where both A and B refer to a symbol defined in C. Link it once statically, and once dynamically, and look at the total sizes of the dynamic/relocation/etc sections across the one/three libraries; you will discover that the latter is slightly larger. The bigger and more complex your program, and the more cross-library references you have, the worse this increase will be, but even a single reference will show an increase of a few bytes.
 
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;
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.

No, because of paging the data is *not* loaded in memory until needed: relocation processing causes it to be needed immediately, and thus relocation causes more disk IO. It is absolutely not true that all the data must be loaded from disk anyway; if you believe this then you really do not understand how paging works at all.
 

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.
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.
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.

The dynamic loader is not part of the application; it's part of the system (this is true on all platforms, not just android). Android never normally runs executables because of its Java-based runtime environment, it only loads shared libraries, so this isn't the best platform to use as an example.

Again, you are just repeating your claim without understanding how paging and relocation processing actually works; if you understand my point above about the increased number of relocations caused by splitting into multiple libraries it should be obvious why it's much slower to have more libraries.
 

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).
Is it now. They're both the same concept.

The same concept implemented very differently, with different styles of code generation and different ways of handing relocations and dynamic symbols. There are many minor variations between OSes in exactly how these things work, but the split between systems that use the shared object model and systems that use the DLL model is significant and major.
 
 
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.

I absolutely do understand how paging, relocation processing, dynamic loading, etc work, as I've implemented, maintained, debugged and analysed maintained various parts of those mechanisms for multiple operating systems. Even so, I don't consider this a topic that anyone can just make offhand statements about without doing very careful and specific tests, even myself; it's just that hard.
 
That, or you do you know your stuff, and simply think I'm not capable of understanding it too.

I didn't make any comment about whether you are *capable* of understanding it: I'm sure you are capable of understanding it. However, your comments on this thread make it very clear that *currently you do not*, and you have a lot to learn about these topics :)
 
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.

Yes, there is a significant overhead to downloading and loading lots of separate javascript libraries. This is why many web development pipelines, when making a production release, squish all the javascript together into a single file that can be loaded as efficiently as possible.
 


[..]

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).
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).

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).
Can you show me where I am confused about that?

You talk about threads corrupting different task's data as a stability risk, but the boundary that's interesting for stability is between different processes which do not, generally, share writable data structures and thus this kind of corruption mostly isn't relevant.
 

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.
Yes! Sounds like all that is well covered!

[]

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)
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.
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.

Nobody claimed the space savings were a reason to drop support; just that if we did drop support, we would also get a space saving, which is a benefit.
 
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.

You can't do a cost/benefit analysis on a decision correctly unless you identify all the costs and all the benefits.
 
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.

and are overlooking the bigger picture :)
Yes indeed :-)
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.

It is loading more messages.
0 new messages