Please unsubscribes me On Sun, 20 Jan 2019 at 12:40 PM, <[email protected]> wrote:
> Send es-discuss mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: es-discuss <[email protected]> > 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 > [email protected] > www.isiahmeadows.com > > > > > ---------- Forwarded message ---------- > From: kai zhu <[email protected]> > To: Isiah Meadows <[email protected]> > Cc: es-discuss <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > > > > > ---------- Forwarded message ---------- > From: Isiah Meadows <[email protected]> > To: kai zhu <[email protected]> > Cc: es-discuss <[email protected]> > 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 > [email protected] > www.isiahmeadows.com > > On Sun, Jan 20, 2019 at 12:33 AM kai zhu <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 > >> [email protected] > >> https://mail.mozilla.org/listinfo/es-discuss > > > > > > > > > ---------- Forwarded message ---------- > From: kai zhu <[email protected]> > To: Isiah Meadows <[email protected]> > Cc: es-discuss <[email protected]> > 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 <[email protected]> > 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 > > [email protected] > > www.isiahmeadows.com > > > > On Sun, Jan 20, 2019 at 12:33 AM kai zhu <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 > >>> [email protected] > >>> https://mail.mozilla.org/listinfo/es-discuss > >> > >> > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
