es-discuss Digest, Vol 143, Issue 41

Kashan Zaheer kashan.zaheer at seventechnology.co.uk
Sun Jan 20 07:41:50 UTC 2019


Please unsubscribes me
On Sun, 20 Jan 2019 at 12:40 PM, <es-discuss-request at mozilla.org> wrote:

> Send es-discuss mailing list submissions to
>         es-discuss at mozilla.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.mozilla.org/listinfo/es-discuss
> or, via email, send a message with subject or body 'help' to
>         es-discuss-request at mozilla.org
>
> You can reach the person managing the list at
>         es-discuss-owner at mozilla.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of es-discuss digest..."
> Today's Topics:
>
>    1. PSA: You can find existing proposals at
>       https://github.com/tc39/proposals (Isiah Meadows)
>    2. Re: RegExp.prototype.count (kai zhu)
>    3. Re: RegExp.prototype.count (Isiah Meadows)
>    4. Re: RegExp.prototype.count (kai zhu)
>
>
>
> ---------- Forwarded message ----------
> From: Isiah Meadows <isiahmeadows at gmail.com>
> To: es-discuss <es-discuss at mozilla.org>
> Cc:
> Bcc:
> Date: Sat, 19 Jan 2019 20:35:50 -0500
> Subject: PSA: You can find existing proposals at
> https://github.com/tc39/proposals
> Not TC39, so don't read this as official communication.
>
> I've lately been seeing the occasional suggestion that's already been
> considered by TC39 and accepted, so I just wanted to give a public
> service announcement that you can find all the various existing
> proposals TC39 has considered (Stage 1-4), as well as many conceptual
> proposals that members have created and championed but haven't yet
> brought before the committee (Stage 0), here:
> https://github.com/tc39/proposals
>
> That repository includes a few interesting things proposed in the last
> few months on this list, such as:
>
> - Upgraded `switch`: https://github.com/tc39/proposal-pattern-matching
> - Stack trace analysis: https://github.com/tc39/proposal-error-stacks
> - Placeholder syntax: https://github.com/tc39/proposal-partial-application
> - Python `with` syntax: https://github.com/tc39/proposal-using-statement
>
> So before you propose something, please check there first. You might
> find it's already being considered, and if your proposal would differ
> significantly from theirs and you feel yours is better, it's best to
> give feedback in that proposal's repo, so it's more likely to get
> noticed and heard by the appropriate audience.
>
> -----
>
> Isiah Meadows
> contact at isiahmeadows.com
> www.isiahmeadows.com
>
>
>
>
> ---------- Forwarded message ----------
> From: kai zhu <kaizhu256 at gmail.com>
> To: Isiah Meadows <isiahmeadows at gmail.com>
> Cc: es-discuss <es-discuss at mozilla.org>
> Bcc:
> Date: Sat, 19 Jan 2019 23:33:50 -0600
> Subject: Re: RegExp.prototype.count
> benchmarked @isiah’s while-loop test-case vs str.split vs str.replace for
> regexp counting on jsperf.com [1], and the results were surprising (for
> me).
>
> benchmarks using 1mb random ascii-string from fastest to slowest.
> 1. (fastest - 1,700 runs/sec) regexp-counting with ```largeCode.split(/\n/).length
> - 1```
> 2. (40% slower - 1000 runs/sec) regexp-counting with ```while-loop
> (/n/g)```
> 3. (60% slower - 700 runs/sec) regexp-counting with ```largeCode.replace((/[^\n]+/g),
> "").length```
>
> looks like the go-to design-pattern for counting-regexp is
> ```str.split(<regexp>).length - 1```
>
> [1] regexp counting 2
> https://jsperf.com/regexp-counting-2
>
> On 13 Jan 2019, at 9:15 PM, Isiah Meadows <isiahmeadows at gmail.com> wrote:
>
> If performance is an issue, regular expressions are likely to be too slow
> to begin with. But you could always do this to count the number of lines in
> a particular string:
>
> ```js
> var count = 0
> var re = /\n|\r\n?/g
> while (re.test(str)) count++
> console.log(count)
> ```
>
> Given it's already this easy to iterate something with a regexp, I'm not
> convinced it's necessary to add this property/method.
> On Sat, Jan 12, 2019 at 17:29 kai zhu <kaizhu256 at gmail.com> wrote:
>
>> a common use-case i have is counting newlines in largish (> 200kb)
>> embedded-js files, like this real-world example [1].  ultimately meant for
>> line-number-preservation purposes in auto-lint/auto-prettify tasks (which
>> have been getting slower due to complexity).
>>
>> would a new RegExp count-method like ```(/\n/g).count(largeCode)``` be
>> significantly more efficient than existing ```largeCode.split("\n").length
>> - 1``` or ```largeCode.replace((/[^\n]+/g), "").length```?
>>
>> -kai
>>
>> [1] calculating and reproducing line-number offsets when
>> linting/autofixing files
>>
>> https://github.com/kaizhu256/node-utility2/blob/2018.12.30/lib.jslint.js#L7377
>>
>> https://github.com/kaizhu256/node-utility2/blob/2018.12.30/lib.jslint.js#L7586
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
>
> ---------- Forwarded message ----------
> From: Isiah Meadows <isiahmeadows at gmail.com>
> To: kai zhu <kaizhu256 at gmail.com>
> Cc: es-discuss <es-discuss at mozilla.org>
> Bcc:
> Date: Sun, 20 Jan 2019 01:22:30 -0500
> Subject: Re: RegExp.prototype.count
> Nit: you should use `.spilt(/\n/g)` to get all parts.
>
> I like the benchmarks here. That's much appreciated, and after further
> investigation, I found a *giant* WTF:
> https://jsperf.com/regexp-counting-2/8
>
> TL;DR: for string character counting, prefer `indexOf`.
>
> For similar reasons to that JSPerf thing, I'd like it to be on the
> String prototype rather than the RegExp prototype, as in
> `str.count(/\n/)`.
>
> -----
>
> Isiah Meadows
> contact at isiahmeadows.com
> www.isiahmeadows.com
>
> On Sun, Jan 20, 2019 at 12:33 AM kai zhu <kaizhu256 at gmail.com> wrote:
> >
> > benchmarked @isiah’s while-loop test-case vs str.split vs str.replace
> for regexp counting on jsperf.com [1], and the results were surprising
> (for me).
> >
> > benchmarks using 1mb random ascii-string from fastest to slowest.
> > 1. (fastest - 1,700 runs/sec) regexp-counting with
> ```largeCode.split(/\n/).length - 1```
> > 2. (40% slower - 1000 runs/sec) regexp-counting with ```while-loop
> (/n/g)```
> > 3. (60% slower - 700 runs/sec) regexp-counting with
> ```largeCode.replace((/[^\n]+/g), "").length```
> >
> > looks like the go-to design-pattern for counting-regexp is
> ```str.split(<regexp>).length - 1```
> >
> > [1] regexp counting 2
> > https://jsperf.com/regexp-counting-2
> >
> > On 13 Jan 2019, at 9:15 PM, Isiah Meadows <isiahmeadows at gmail.com>
> wrote:
> >
> > If performance is an issue, regular expressions are likely to be too
> slow to begin with. But you could always do this to count the number of
> lines in a particular string:
> >
> > ```js
> > var count = 0
> > var re = /\n|\r\n?/g
> > while (re.test(str)) count++
> > console.log(count)
> > ```
> >
> > Given it's already this easy to iterate something with a regexp, I'm not
> convinced it's necessary to add this property/method.
> > On Sat, Jan 12, 2019 at 17:29 kai zhu <kaizhu256 at gmail.com> wrote:
> >>
> >> a common use-case i have is counting newlines in largish (> 200kb)
> embedded-js files, like this real-world example [1].  ultimately meant for
> line-number-preservation purposes in auto-lint/auto-prettify tasks (which
> have been getting slower due to complexity).
> >>
> >> would a new RegExp count-method like ```(/\n/g).count(largeCode)``` be
> significantly more efficient than existing ```largeCode.split("\n").length
> - 1``` or ```largeCode.replace((/[^\n]+/g), "").length```?
> >>
> >> -kai
> >>
> >> [1] calculating and reproducing line-number offsets when
> linting/autofixing files
> >>
> https://github.com/kaizhu256/node-utility2/blob/2018.12.30/lib.jslint.js#L7377
> >>
> https://github.com/kaizhu256/node-utility2/blob/2018.12.30/lib.jslint.js#L7586
> >>
> >> _______________________________________________
> >> es-discuss mailing list
> >> es-discuss at mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >
> >
>
>
>
>
> ---------- Forwarded message ----------
> From: kai zhu <kaizhu256 at gmail.com>
> To: Isiah Meadows <isiahmeadows at gmail.com>
> Cc: es-discuss <es-discuss at mozilla.org>
> Bcc:
> Date: Sun, 20 Jan 2019 01:40:00 -0600
> Subject: Re: RegExp.prototype.count
> +1 for string.count
>
> i don’t think the g-flag is necessary in str.split, so the original
> performance claims are still valid:
> - for counting regexp - use split + length
> - for counting substring - use while + indexOf
>
> > On 20 Jan 2019, at 12:22 AM, Isiah Meadows <isiahmeadows at gmail.com>
> wrote:
> >
> > Nit: you should use `.spilt(/\n/g)` to get all parts.
> >
> > I like the benchmarks here. That's much appreciated, and after further
> > investigation, I found a *giant* WTF:
> > https://jsperf.com/regexp-counting-2/8
> >
> > TL;DR: for string character counting, prefer `indexOf`.
> >
> > For similar reasons to that JSPerf thing, I'd like it to be on the
> > String prototype rather than the RegExp prototype, as in
> > `str.count(/\n/)`.
> >
> > -----
> >
> > Isiah Meadows
> > contact at isiahmeadows.com
> > www.isiahmeadows.com
> >
> > On Sun, Jan 20, 2019 at 12:33 AM kai zhu <kaizhu256 at gmail.com> wrote:
> >>
> >> benchmarked @isiah’s while-loop test-case vs str.split vs str.replace
> for regexp counting on jsperf.com [1], and the results were surprising
> (for me).
> >>
> >> benchmarks using 1mb random ascii-string from fastest to slowest.
> >> 1. (fastest - 1,700 runs/sec) regexp-counting with
> ```largeCode.split(/\n/).length - 1```
> >> 2. (40% slower - 1000 runs/sec) regexp-counting with ```while-loop
> (/n/g)```
> >> 3. (60% slower - 700 runs/sec) regexp-counting with
> ```largeCode.replace((/[^\n]+/g), "").length```
> >>
> >> looks like the go-to design-pattern for counting-regexp is
> ```str.split(<regexp>).length - 1```
> >>
> >> [1] regexp counting 2
> >> https://jsperf.com/regexp-counting-2
> >>
> >> On 13 Jan 2019, at 9:15 PM, Isiah Meadows <isiahmeadows at gmail.com>
> wrote:
> >>
> >> If performance is an issue, regular expressions are likely to be too
> slow to begin with. But you could always do this to count the number of
> lines in a particular string:
> >>
> >> ```js
> >> var count = 0
> >> var re = /\n|\r\n?/g
> >> while (re.test(str)) count++
> >> console.log(count)
> >> ```
> >>
> >> Given it's already this easy to iterate something with a regexp, I'm
> not convinced it's necessary to add this property/method.
> >> On Sat, Jan 12, 2019 at 17:29 kai zhu <kaizhu256 at gmail.com> wrote:
> >>>
> >>> a common use-case i have is counting newlines in largish (> 200kb)
> embedded-js files, like this real-world example [1].  ultimately meant for
> line-number-preservation purposes in auto-lint/auto-prettify tasks (which
> have been getting slower due to complexity).
> >>>
> >>> would a new RegExp count-method like ```(/\n/g).count(largeCode)``` be
> significantly more efficient than existing ```largeCode.split("\n").length
> - 1``` or ```largeCode.replace((/[^\n]+/g), "").length```?
> >>>
> >>> -kai
> >>>
> >>> [1] calculating and reproducing line-number offsets when
> linting/autofixing files
> >>>
> https://github.com/kaizhu256/node-utility2/blob/2018.12.30/lib.jslint.js#L7377
> >>>
> https://github.com/kaizhu256/node-utility2/blob/2018.12.30/lib.jslint.js#L7586
> >>>
> >>> _______________________________________________
> >>> es-discuss mailing list
> >>> es-discuss at mozilla.org
> >>> https://mail.mozilla.org/listinfo/es-discuss
> >>
> >>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190120/aaec6dd7/attachment-0001.html>


More information about the es-discuss mailing list