Using faster url parser

[petkaantonov]

(Original node issue nodejs/node-v0.x-archive#6788)

I have rewritten the url parser module of node core as it was/is a serious bottleneck in some of the techempower benchmarks

Running node's urlparser benchmark using iojs it's still 16x faster when not retrieving properties and 11x faster when retrieving all properties (which are lazy getters in my implementation). In absolute terms the current iojs urlparser throughputs 25k parses per second vs 400k lazy/270k eager parses per second. format and resolve are also affected in similar magnitudes.

[rvagg]

a pull request or some other request for specific action is likely to get more attention here fwiw

[petkaantonov]

Well I request your opinion before I make it PR ready (it's a normal user module right now)

[vkurchatkin]

I like the idea of making url faster, but replacing the whole module frightens me a little

[xaka]

I think there is nothing wrong with using faster parser as it's just an
implementation details as long as API stays the same and all existing tests
pass

On Wed, Jan 28, 2015 at 1:39 PM, Vladimir Kurchatkin <
notifications@github.com> wrote:

I like the idea of making url faster, but replacing the whole module
frightens me a little

—
Reply to this email directly or view it on GitHub
#643 (comment).

[runeli]

I would love to see this on io

[vkurchatkin]

@xaka It's about subtle things, like data properties vs. accessor properties. It's hard to foresee everything once whole module changes. This requires major version bump at least.

[xaka]

That's a good point. Switching from properties to accessors means breaking
API as things like console.log(...) would work differently and people might
be using the stdout for instance for their own reasons, etc.

On Wed, Jan 28, 2015 at 2:36 PM, Vladimir Kurchatkin <
notifications@github.com> wrote:

@xaka https://github.com/xaka It's about subtle things, like data
properties vs. accessor properties. It's hard to foresee everything once
whole module changes. This requires major version bump at least.

—
Reply to this email directly or view it on GitHub
#643 (comment).

[jonathanong]

this is one of the reasons why i'm trying to get rid of the util._extend() usage. otherwise, i fear too much would break.

[mikeal]

Can't we lazily patch the stringify and json transforms to avoid API change/break?

[petkaantonov]

The getters can be made enumerable (but they're still on the prototype) and the Url class can implement toJSON method. So that leaves util._extend(), which should be internal method?

It can also be considered to make the properties just eager data properties, it would still be 11x faster. But often many of the properties are not needed (especially .href?) so it could be a bummer.

[rvagg]

fixed at #1561