Very slow code
See original GitHub issueHello.
This code - https://jsfiddle.net/h3xzgre3/
Clear: 17.44 ms
Compact: 17.68 ms
Encoding OFF: 259.62 ms
Encoding BASE64: 333.79 ms
Encoding RC4: 356.6 ms
Reducing the speed of the code in 2000% (356ms/17ms)
Why is this happening?
Issue Analytics
- State:
- Created 6 years ago
- Comments:15 (10 by maintainers)
Top Results From Across the Web
Slow code - Wikipedia
Slow code refers to the practice in a hospital or other medical centre to purposely respond slowly or incompletely to a patient in...
Read more >Why Not a Slow Code? - AMA Journal of Ethics
Ethical Issues. Deceit. A slow code gives the appearance that something is being done that is expected to be effective, and the physician...
Read more >Ethical Considerations When Nurses Perform 'Slow Codes' at ...
Slow codes still are not talked about openly. The controversial practice “is often considered deceitful and unethical; therefore, the practice is shrouded ...
Read more >“Slow” Code: Perspectives of a Physician and Critical Care ...
"SLOW" codes are a cardiopulmonary resuscitative efforts "that involve a deliberative decision not to attempt aggressively to bring a patient back to life....
Read more >Why am I coding so slow? How do I improve? - Quora
Writing code slowly is perfectly normal, even among experienced engineers. The act of writing code is the easy part, all the time in...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
No. I tried with simple object and map caches and got same or even longer results.
Also, half of additional time takes calls to StringArrayCallsWrapper function, so even without string to number conversion - time around 120-130ms in test.
So, i think - add additional post-obfuscation optimisation stage with various transformers (right now - single) - good choice.
This transformer will look AST-tree for for-in loops with 1000+ iterations, and move all StringArrayCallsWrapper calls outside of array.
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.