Closed jasonpang closed 8 years ago
Results for 200 iterations:
Time Taken (using new txtarea each time): 0.0018800000000000238 seconds.
Time Taken (using same txtarea): 0.0008049999999999784 seconds.
Time Taken (using HtmlEntities library function): 0.005325000000000017 seconds.
Results using 100,000 iterations:
Time Taken (using new txtarea each time): 1.6731399999999998 seconds.
Time Taken (using same txtarea): 0.6872499999999996 seconds.
Time Taken (using HtmlEntities library function): 3.0460450000000003 seconds.
Testing on Mac 10.11.1: Chrome 48.0.2564.116, Firefox 45.0, and Safari9.0.1. The results were pretty consistent across all browsers except on Safari, the HtmlEntites library test (last test) was 1.6x longer instead of 2x longer than the first test (using new txtarea each time).
You’re comparing apples and oranges — he implements the spec, which not all browsers support fully. Try this test page: https://mathias.html5.org/tests/html/named-character-references/
Æ
: https://bugs.webkit.org/show_bug.cgi?id=87465 (now fixed)
,  
, and  
in IE/Edge: https://connect.microsoft.com/IE/feedback/details/743819 (still present)As for performance, if you see any way to improve it in he without increasing complexity too much, please submit a pull request.
I see Mathias, thanks for the detailed response and sorry for the faulty comparison!
Hello,
Thanks for all your hard work on the library and the awesome documentation!
I did a performance test recently between he.decode() and using this trick to use the browser's
<textarea>
element to do the conversion for me.Surprisingly, I found that
he.decode()
was 2x slower for my string than using the browser's textarea. Here is the code I used to run my benchmarks. The<script>
src at the top should be changed to point to yourhe.js
script location:Just wanted to point out this interesting comparison. It isn't really an issue so you can close this!