guest271314 (2019-05-25T22:02:13.000Z)
guest271314 at gmail.com (2019-05-26T02:47:12.042Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be tested and compared and benchmarked? The same code being used at different computers; or different code used at the same computer? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset one primary limiting factor as to "how many" would probably be the available RAM and hard disk space of the computer used (and browser preferences; cache policies; configuration) to load the modules (before the browser/OS freezes), similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467 ; https://stackoverflow.com/questions/39959467#comment67315240_40017582) where the result can vary considerably when testing code on different computers, depending on available RAM and hard-disk space of the computer (for example, comparing results at a minimal OS at Raspberry Pi with 500MB of available RAM and the same OS having 16GB RAM; or a non-minimal OS with multiple applications and the browser running compared to only the browser application running; including or not including the cost of loading the code which loads the async modules - if the code is not shipped with the browser - in the test results; etc.). The tentative answer to the original question "how many async-modules can js-app practically load?" would be until memory and available disk space runs out. Tests of such code should also include the hardware and software used for the test and perform the various tests at the same computer - which will be compared to the other tests performed at the same computer, locally. Then those test results can be compared to different architectures, browsers (browsers implement specifications and code differently; consider Why does Firefox produce larger WebM video files compared with Chrome? https://stackoverflow.com/q/54651869 "However, Firefox still ends up creating up to 4 times larger files compared with Chrome."; https://stackoverflow.com/a/54652768 "Because they don't use the same settings..."; https://gist.github.com/guest271314/f942fb9febd9c197bd3824973794ba3e ; https://gist.github.com/guest271314/17d62bf74a97d3f111aa25605a9cd1ca), OS's, configurations to create a graph of the various combinations for comparative analysis. Online tests of code (e.g. jsPerf) can provide inaccurate results, see https://stackoverflow.com/questions/46516234#comment80198567_46623314 ; microbenchmarks fairy tale https://mrale.ph/blog/2012/12/15/microbenchmarks-fairy-tale.html (note also the list item links at this answer https://stackoverflow.com/a/47173390 at Why is using a loop to iterate from start of array to end faster than iterating both start to end and end to start? https://stackoverflow.com/q/47049004); Is TIO acceptable for fastest-code questions? https://codegolf.meta.stackexchange.com/q/12707 ; https://codegolf.meta.stackexchange.com/a/12708 > Unfortunately, I don't think TIO is a very reliable way of timing code, even if counting CPU time rather than wall time. > > First of all, TIO uses multiple arena servers, where all user-supplied code is run. At point, there are only two arenas and both have identical specs, but even now, one of them is consistently and considerably slower than the other. I have no idea why this happens, but it does. > > Also – and this applies to all method of timing code – two processes running at the same time can affect each other in subtle ways that will impact CPU time. E.g., speed of memory access may be affected, especially if the data should already be in the CPU's cache, but was pushed out by another process. Computers also tend to be measurably faster after a restart. > > Of course, running code on TIO is still better than having everyone time their code on their own machines. I wouldn't even consider the latter an objective winning criterion for a fastest-code challenge. https://codegolf.meta.stackexchange.com/questions/12707#comment43256_12708 > Sorry, I meant having people time their code on their own machines. That's a fastest-computer challenge, not a fastest-code challenge. There's also no way of verifying the scores. Again, have not tried babel or webpack for the purpose of loading modules. Where possible, try to use only and test code that is shipped with FOSS browsers, when the code is being used in the FOSS browser.
guest271314 at gmail.com (2019-05-26T02:46:51.206Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be tested and compared and benchmarked? The same code being used at different computers; or different code used at the same computer? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset one primary limiting factor as to "how many" would probably be the available RAM and hard disk space of the computer used (and browser preferences; cache policies; configuration) to load the modules (before the browser/OS freezes), similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467 ; https://stackoverflow.com/questions/39959467#comment67315240_40017582) where the result can vary considerably when testing code on different computers, depending on available RAM and hard-disk space of the computer (for example, comparing results at a minimal OS at Raspberry Pi with 500MB of available RAM and the same OS having 16GB RAM; or a non-minimal OS with multiple applications and the browser running compared to only the browser application running; including or not including the cost of loading the code which loads the async modules - if the code is not shipped with the browser - in the test results; etc.). The tentative answer to the original question "how many async-modules can js-app practically load?" would be until memory and available disk space runs out. Tests of such code should also include the hardware and software used for the test and perform the various tests at the same computer - which will be compared to the other tests performed at the same computer, locally. Then those test results can be compared to different architectures, browsers (browsers implement specifications and code differently; consider Why does Firefox produce larger WebM video files compared with Chrome? https://stackoverflow.com/q/54651869 "However, Firefox still ends up creating up to 4 times larger files compared with Chrome."; https://stackoverflow.com/a/54652768 "Because they don't use the same settings..."; https://gist.github.com/guest271314/f942fb9febd9c197bd3824973794ba3e; https://gist.github.com/guest271314/17d62bf74a97d3f111aa25605a9cd1ca), OS's, configurations to create a graph of the various combinations for comparative analysis. Online tests of code (e.g. jsPerf) can provide inaccurate results, see https://stackoverflow.com/questions/46516234#comment80198567_46623314 ; microbenchmarks fairy tale https://mrale.ph/blog/2012/12/15/microbenchmarks-fairy-tale.html (note also the list item links at this answer https://stackoverflow.com/a/47173390 at Why is using a loop to iterate from start of array to end faster than iterating both start to end and end to start? https://stackoverflow.com/q/47049004); Is TIO acceptable for fastest-code questions? https://codegolf.meta.stackexchange.com/q/12707 ; https://codegolf.meta.stackexchange.com/a/12708 > Unfortunately, I don't think TIO is a very reliable way of timing code, even if counting CPU time rather than wall time. > > First of all, TIO uses multiple arena servers, where all user-supplied code is run. At point, there are only two arenas and both have identical specs, but even now, one of them is consistently and considerably slower than the other. I have no idea why this happens, but it does. > > Also – and this applies to all method of timing code – two processes running at the same time can affect each other in subtle ways that will impact CPU time. E.g., speed of memory access may be affected, especially if the data should already be in the CPU's cache, but was pushed out by another process. Computers also tend to be measurably faster after a restart. > > Of course, running code on TIO is still better than having everyone time their code on their own machines. I wouldn't even consider the latter an objective winning criterion for a fastest-code challenge. https://codegolf.meta.stackexchange.com/questions/12707#comment43256_12708 > Sorry, I meant having people time their code on their own machines. That's a fastest-computer challenge, not a fastest-code challenge. There's also no way of verifying the scores. Again, have not tried babel or webpack for the purpose of loading modules. Where possible, try to use only and test code that is shipped with FOSS browsers, when the code is being used in the FOSS browser.
guest271314 at gmail.com (2019-05-26T00:13:15.598Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be tested and compared and benchmarked? The same code being used at different computers; or different code used at the same computer? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset one primary limiting factor as to "how many" would probably be the available RAM and hard disk space of the computer used (and browser preferences; cache policies; configuration) to load the modules (before the browser/OS freezes), similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467 ; https://stackoverflow.com/questions/39959467#comment67315240_40017582) where the result can vary considerably when testing code on different computers, depending on available RAM and hard-disk space of the computer (for example, comparing results at a minimal OS at Raspberry Pi with 500MB of available RAM and the same OS having 16GB RAM; or a non-minimal OS with multiple applications and the browser running compared to only the browser application running; including or not including the cost of loading the code which loads the async modules - if the code is not shipped with the browser - in the test results; etc.). The tentative answer to the original question "how many async-modules can js-app practically load?" would be until memory and available disk space runs out. Tests of such code should also include the hardware and software used for the test and perform the various tests at the same computer - which will be compared to the other tests performed at the same computer, locally. Online tests of code (e.g. jsPerf) can provide inaccurate results, see https://stackoverflow.com/questions/46516234#comment80198567_46623314 ; microbenchmarks fairy tale https://mrale.ph/blog/2012/12/15/microbenchmarks-fairy-tale.html (note also the list item links at this answer https://stackoverflow.com/a/47173390 at Why is using a loop to iterate from start of array to end faster than iterating both start to end and end to start? https://stackoverflow.com/q/47049004); Is TIO acceptable for fastest-code questions? https://codegolf.meta.stackexchange.com/q/12707 ; https://codegolf.meta.stackexchange.com/a/12708 > Unfortunately, I don't think TIO is a very reliable way of timing code, even if counting CPU time rather than wall time. > > First of all, TIO uses multiple arena servers, where all user-supplied code is run. At point, there are only two arenas and both have identical specs, but even now, one of them is consistently and considerably slower than the other. I have no idea why this happens, but it does. > > Also – and this applies to all method of timing code – two processes running at the same time can affect each other in subtle ways that will impact CPU time. E.g., speed of memory access may be affected, especially if the data should already be in the CPU's cache, but was pushed out by another process. Computers also tend to be measurably faster after a restart. > > Of course, running code on TIO is still better than having everyone time their code on their own machines. I wouldn't even consider the latter an objective winning criterion for a fastest-code challenge. https://codegolf.meta.stackexchange.com/questions/12707#comment43256_12708 > Sorry, I meant having people time their code on their own machines. That's a fastest-computer challenge, not a fastest-code challenge. There's also no way of verifying the scores. Again, have not tried babel or webpack for the purpose of loading modules. Where possible, try to use only and test code that is shipped with FOSS browsers, when the code is being used in the FOSS browser.
guest271314 at gmail.com (2019-05-26T00:08:35.794Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be tested and compared and benchmarked? The same code being used at different computers; or different code used at the same computer? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset one primary limiting factor as to "how many" would probably be the available RAM and hard disk space of the computer used (and browser preferences; cache policies; configuration) to load the modules (before the browser/OS freezes), similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467 ; https://stackoverflow.com/questions/39959467#comment67315240_40017582) where the result can vary considerably when testing code on different computers, depending on available RAM and hard-disk space of the computer (for example, comparing results at a minimal OS at Raspberry Pi with 500MB of available RAM and the same OS having 16GB RAM; or a non-minimal OS with multiple applications and the browser running compared to only the browser application being running, etc.). The tentative answer to the original question "how many async-modules can js-app practically load?" would be until memory and available disk space runs out. Tests of such code should also include the hardware and software used for the test and perform the various tests at the same computer - which will be compared to the other tests performed at the same computer, locally. Online tests of code (e.g. jsPerf) can provide inaccurate results, see https://stackoverflow.com/questions/46516234#comment80198567_46623314 ; microbenchmarks fairy tale https://mrale.ph/blog/2012/12/15/microbenchmarks-fairy-tale.html (note also the list item links at this answer https://stackoverflow.com/a/47173390 at Why is using a loop to iterate from start of array to end faster than iterating both start to end and end to start? https://stackoverflow.com/q/47049004); Is TIO acceptable for fastest-code questions? https://codegolf.meta.stackexchange.com/q/12707 ; https://codegolf.meta.stackexchange.com/a/12708 > Unfortunately, I don't think TIO is a very reliable way of timing code, even if counting CPU time rather than wall time. > > First of all, TIO uses multiple arena servers, where all user-supplied code is run. At point, there are only two arenas and both have identical specs, but even now, one of them is consistently and considerably slower than the other. I have no idea why this happens, but it does. > > Also – and this applies to all method of timing code – two processes running at the same time can affect each other in subtle ways that will impact CPU time. E.g., speed of memory access may be affected, especially if the data should already be in the CPU's cache, but was pushed out by another process. Computers also tend to be measurably faster after a restart. > > Of course, running code on TIO is still better than having everyone time their code on their own machines. I wouldn't even consider the latter an objective winning criterion for a fastest-code challenge. https://codegolf.meta.stackexchange.com/questions/12707#comment43256_12708 > Sorry, I meant having people time their code on their own machines. That's a fastest-computer challenge, not a fastest-code challenge. There's also no way of verifying the scores. Again, have not tried babel or webpack for the purpose of loading modules. Where possible, try to use only and test code that is shipped with FOSS browsers, when the code is being used in the FOSS browser.
guest271314 at gmail.com (2019-05-26T00:07:10.992Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be tested and compared and benchmarked? The same code being used at different computers; or different code used at the same computer? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset one primary limiting factor as to "how many" would probably be the available RAM and hard disk space of the computer used (and browser preferences; cache policies; configuration) to load the modules (before the browser/OS freezes), similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467 ; https://stackoverflow.com/questions/39959467#comment67315240_40017582) where the result can vary considerably when testing code on different computers, depending on available RAM and hard-disk space of the computer (for example, comparing results at a minimal OS at Raspberry Pi with 500MB of available RAM and the same OS having 16GB RAM; or a non-minimal OS with multiple applications and the browser running compared to only the browser application being running, etc.). The tentative answer to the original question "how many async-modules can js-app practically load?" would be until memory and available disk space runs out. Tests of such code should also include the hardware and software used for the test and perform the various tests at the same computer - which will be compared to the other tests performed at the same computer, locally. Online tests of code (e.g. jsPerf) can provide inaccurate results, see https://stackoverflow.com/questions/46516234#comment80198567_46623314 ; microbenchmarks fairy tale https://mrale.ph/blog/2012/12/15/microbenchmarks-fairy-tale.html (note also the list item links at this answer https://stackoverflow.com/a/47173390 at Why is using a loop to iterate from start of array to end faster than iterating both start to end and end to start? https://stackoverflow.com/q/47049004); Is TIO acceptable for fastest-code questions? https://codegolf.meta.stackexchange.com/q/12707 ; https://codegolf.meta.stackexchange.com/a/12708 > Unfortunately, I don't think TIO is a very reliable way of timing code, even if counting CPU time rather than wall time. > > First of all, TIO uses multiple arena servers, where all user-supplied code is run. At point, there are only two arenas and both have identical specs, but even now, one of them is consistently and considerably slower than the other. I have no idea why this happens, but it does. > > Also – and this applies to all method of timing code – two processes running at the same time can affect each other in subtle ways that will impact CPU time. E.g., speed of memory access may be affected, especially if the data should already be in the CPU's cache, but was pushed out by another process. Computers also tend to be measurably faster after a restart. > > Of course, running code on TIO is still better than having everyone time their code on their own machines. I wouldn't even consider the latter an objective winning criterion for a fastest-code challenge. https://codegolf.meta.stackexchange.com/questions/12707#comment43256_12708 > Sorry, I meant having people time their code on their own machines. That's a fastest-computer challenge, not a fastest-code challenge. There's also no way of verifying the scores. Again, have not tried babel or webpack for the purpose of loading modules. Where possible try to use only and test code that is shipped with FOSS browsers, when the code is being used in the FOSS browser.
guest271314 at gmail.com (2019-05-25T23:57:44.641Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be tested and compared and benchmarked? The same code being used at different computers; or different code used at the same computer? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset one primary limiting factor as to "how many" would probably be the available RAM and hard disk space of the computer used (and browser preferences; cache policies; configuration) to load the modules (before the browser/OS freezes), similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467 ; https://stackoverflow.com/questions/39959467#comment67315240_40017582) where the result can vary considerably when testing code on different computers, depending on available RAM and hard-disk space of the computer (for example, comparing results at a minimal OS at Raspberry Pi with 500MB of available RAM and the same OS having 16GB RAM; or a non-minimal OS with multiple applications and the browser running compared to only the browser application being running, etc.). The tentative answer to the original question "how many async-modules can js-app practically load?" would be until memory and available disk space runs out. Tests of such code should also include the hardware and software used for the test and perform the various tests at the same computer - which will be compared to the other tests performed at the same computer, locally. Online tests of code (e.g. jsPerf) can provide inaccurate results, see https://stackoverflow.com/questions/46516234#comment80198567_46623314 ; microbenchmarks fairy tale https://mrale.ph/blog/2012/12/15/microbenchmarks-fairy-tale.html (note also the list item links at this answer https://stackoverflow.com/a/47173390 at Why is using a loop to iterate from start of array to end faster than iterating both start to end and end to start? https://stackoverflow.com/q/47049004); Is TIO acceptable for fastest-code questions? https://codegolf.meta.stackexchange.com/q/12707 ; https://codegolf.meta.stackexchange.com/a/12708 > Unfortunately, I don't think TIO is a very reliable way of timing code, even if counting CPU time rather than wall time. > > First of all, TIO uses multiple arena servers, where all user-supplied code is run. At point, there are only two arenas and both have identical specs, but even now, one of them is consistently and considerably slower than the other. I have no idea why this happens, but it does. > > Also – and this applies to all method of timing code – two processes running at the same time can affect each other in subtle ways that will impact CPU time. E.g., speed of memory access may be affected, especially if the data should already be in the CPU's cache, but was pushed out by another process. Computers also tend to be measurably faster after a restart. > > Of course, running code on TIO is still better than having everyone time their code on their own machines. I wouldn't even consider the latter an objective winning criterion for a fastest-code challenge. https://codegolf.meta.stackexchange.com/questions/12707#comment43256_12708 > Sorry, I meant having people time their code on their own machines. That's a fastest-computer challenge, not a fastest-code challenge. There's also no way of verifying the scores. Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.
guest271314 at gmail.com (2019-05-25T23:52:10.154Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be tested and compared and benchmarked? The same code being used at different computers; or different code used at the same computer? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset one primary limiting factor as to "how many" would probably be the available RAM and hard disk space of the computer used (and browser preferences; cache policies; configuration) to load the modules (before the browser/OS freezes), similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467 ; https://stackoverflow.com/questions/39959467#comment67315240_40017582) where the result can vary considerably when testing code on different computers, depending on available RAM and hard-disk space of the computer (for example, comparing results at a minimal OS at Raspberry Pi with 500MB of available RAM and the same OS having 16GB RAM; or a non-minimal OS with multiple applications and the browser running compared to only the browser application being running, etc.). The tentative answer to the original question "how many async-modules can js-app practically load?" would be until memory and available disk space runs out. Tests of such code should also include the hardware and software used for the test and perform the various tests at the same computer - which will be compared to the other tests performed at the same computer, locally. Online tests of code (e.g. jsPerf) can provide inaccurate results, see https://stackoverflow.com/questions/46516234#comment80198567_46623314 ; microbenchmarks fairy tale https://mrale.ph/blog/2012/12/15/microbenchmarks-fairy-tale.html (note also the list item links at this answer https://stackoverflow.com/a/47173390 at Why is using a loop to iterate from start of array to end faster than iterating both start to end and end to start? https://stackoverflow.com/q/47049004); Is TIO acceptable for fastest-code questions? https://codegolf.meta.stackexchange.com/q/12707 ; https://codegolf.meta.stackexchange.com/a/12708 > Unfortunately, I don't think TIO is a very reliable way of timing code, even if counting CPU time rather than wall time. > > First of all, TIO uses multiple arena servers, where all user-supplied code is run. At point, there are only two arenas and both have identical specs, but even now, one of them is consistently and considerably slower than the other. I have no idea why this happens, but it does. > > Also – and this applies to all method of timing code – two processes running at the same time can affect each other in subtle ways that will impact CPU time. E.g., speed of memory access may be affected, especially if the data should already be in the CPU's cache, but was pushed out by another process. Computers also tend to be measurably faster after a restart. > > Of course, running code on TIO is still better than having everyone time their code on their own machines. I wouldn't even consider the latter an objective winning criterion for a fastest-code challenge. Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.
guest271314 at gmail.com (2019-05-25T23:45:19.480Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be tested and compared? The same code being used at different computers; or different code used at the same computer? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset one primary limiting factor as to "how many" would probably be the available RAM and hard disk space of the computer used (and browser preferences; cache policies; configuration) to load the modules (before the browser/OS freezes), similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467 ; https://stackoverflow.com/questions/39959467#comment67315240_40017582) where the result can vary considerably when testing code on different computers, depending on available RAM and hard-disk space of the computer (for example, comparing results at a minimal OS at Raspberry Pi with 500MB of available RAM and the same OS having 16GB RAM; or a non-minimal OS with multiple applications and the browser running compared to only the browser application being running, etc.). The tentative answer to the original question "how many async-modules can js-app practically load?" would be until memory and available disk space runs out. Tests of such code should also include the hardware and software used for the test and perform the various tests at the same computer - which will be compared to the other tests performed at the same computer, locally. Online tests of code (e.g. jsPerf) can provide inaccurate results, see https://stackoverflow.com/questions/46516234#comment80198567_46623314 ; microbenchmarks fairy tale https://mrale.ph/blog/2012/12/15/microbenchmarks-fairy-tale.html (note also the list item links at this answer https://stackoverflow.com/a/47173390 at Why is using a loop to iterate from start of array to end faster than iterating both start to end and end to start? https://stackoverflow.com/q/47049004); Is TIO acceptable for fastest-code questions? https://codegolf.meta.stackexchange.com/q/12707 ; https://codegolf.meta.stackexchange.com/a/12708 > Unfortunately, I don't think TIO is a very reliable way of timing code, even if counting CPU time rather than wall time. > > First of all, TIO uses multiple arena servers, where all user-supplied code is run. At point, there are only two arenas and both have identical specs, but even now, one of them is consistently and considerably slower than the other. I have no idea why this happens, but it does. > > Also – and this applies to all method of timing code – two processes running at the same time can affect each other in subtle ways that will impact CPU time. E.g., speed of memory access may be affected, especially if the data should already be in the CPU's cache, but was pushed out by another process. Computers also tend to be measurably faster after a restart. > > Of course, running code on TIO is still better than having everyone time their code on their own machines. I wouldn't even consider the latter an objective winning criterion for a fastest-code challenge. Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.
guest271314 at gmail.com (2019-05-25T23:34:18.307Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be tested and compared? The same code being used at different computers; or different code used at the same computer? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset one primary limiting factor as to "how many" would probably be the available RAM and hard disk space of the computer used (and browser preferences; cache policies; configuration) to load the modules (before the browser/OS freezes), similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467 ; https://stackoverflow.com/questions/39959467#comment67315240_40017582) where the result can vary considerably when testing code on different computers, depending on available RAM and hard-disk space of the computer (for example, comparing results at a minimal OS at Raspberry Pi with 500MB of available RAM and the same OS having 16GB RAM; or a non-minimal OS with multiple applications and the browser running compared to only the browser application being running, etc.). The tentative answer to the original question "how many async-modules can js-app practically load?" would be until memory and available disk space runs out. Tests of such code should also include the hardware and software used for the test and perform the various tests at the same computer - which will be compared to the other tests performed at the same computer, locally. Online tests of code (e.g. jsPerf) can provide inaccurate results, see https://stackoverflow.com/questions/46516234#comment80198567_46623314 ; microbenchmarks fairy tale https://mrale.ph/blog/2012/12/15/microbenchmarks-fairy-tale.html; Is TIO acceptable for fastest-code questions? https://codegolf.meta.stackexchange.com/q/12707 ; https://codegolf.meta.stackexchange.com/a/12708 > Unfortunately, I don't think TIO is a very reliable way of timing code, even if counting CPU time rather than wall time. > > First of all, TIO uses multiple arena servers, where all user-supplied code is run. At point, there are only two arenas and both have identical specs, but even now, one of them is consistently and considerably slower than the other. I have no idea why this happens, but it does. > > Also – and this applies to all method of timing code – two processes running at the same time can affect each other in subtle ways that will impact CPU time. E.g., speed of memory access may be affected, especially if the data should already be in the CPU's cache, but was pushed out by another process. Computers also tend to be measurably faster after a restart. > > Of course, running code on TIO is still better than having everyone time their code on their own machines. I wouldn't even consider the latter an objective winning criterion for a fastest-code challenge. Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.
guest271314 at gmail.com (2019-05-25T23:27:34.691Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be tested and compared? The same code being used at different computers; or different code used at the same computer? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset one primary limiting factor as to "how many" would probably be the available RAM and hard disk space of the computer used (and browser preferences, policies, configuration) to load the modules (before the browser/OS freezes), similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467 ; https://stackoverflow.com/questions/39959467#comment67315240_40017582) where the result can vary considerably when testing code on different computers, depending on available RAM and hard-disk space of the computer (for example, comparing results at a minimal OS at Raspberry Pi with 500MB of available RAM and the same OS having 16GB RAM; or a non-minimal OS with multiple applications and the browser running compared to only the browser application being running, etc.). The tentative answer to the original question "how many async-modules can js-app practically load?" would be until memory and available disk space runs out. Tests of such code should also include the hardware and software used for the test and perform the various tests at the same computer - which will be compared to the other tests performed at the same computer, locally. Online tests of code (e.g. jsPerf) can provide inaccurate results, see https://stackoverflow.com/questions/46516234#comment80198567_46623314 ; microbenchmarks fairy tale https://mrale.ph/blog/2012/12/15/microbenchmarks-fairy-tale.html; Is TIO acceptable for fastest-code questions? https://codegolf.meta.stackexchange.com/q/12707 ; https://codegolf.meta.stackexchange.com/a/12708 > Unfortunately, I don't think TIO is a very reliable way of timing code, even if counting CPU time rather than wall time. > > First of all, TIO uses multiple arena servers, where all user-supplied code is run. At point, there are only two arenas and both have identical specs, but even now, one of them is consistently and considerably slower than the other. I have no idea why this happens, but it does. > > Also – and this applies to all method of timing code – two processes running at the same time can affect each other in subtle ways that will impact CPU time. E.g., speed of memory access may be affected, especially if the data should already be in the CPU's cache, but was pushed out by another process. Computers also tend to be measurably faster after a restart. > > Of course, running code on TIO is still better than having everyone time their code on their own machines. I wouldn't even consider the latter an objective winning criterion for a fastest-code challenge. Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.
guest271314 at gmail.com (2019-05-25T23:25:47.019Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be tested and compared? The same code being used at different computers; or different code used at the same computer? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset one primary limiting factor as to "how many" would probably be the available RAM and hard disk space of the computer used (and browser preferences, policies, configuration) to load the modules (before the browser/OS freezes), similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467 ; https://stackoverflow.com/questions/39959467#comment67315240_40017582) where the result can vary considerably when testing code on different computers, depending on available RAM and hard-disk space of the computer (for example, comparing results at a minimal OS at Raspberry Pi with 500MB of available RAM and the same OS having 16GB RAM; or a non-minimal OS with multiple applications and the browser running compared to only the browser application being running, etc.). The tentative answer to the original question "how many async-modules can js-app practically load?" would be until memory and available disk space runs out. Tests of such code should also include the hardware and software used for the test. Online tests of code (e.g. jsPerf) can provide inaccurate results, see https://stackoverflow.com/questions/46516234#comment80198567_46623314 ; microbenchmarks fairy tale https://mrale.ph/blog/2012/12/15/microbenchmarks-fairy-tale.html; Is TIO acceptable for fastest-code questions? https://codegolf.meta.stackexchange.com/q/12707 ; https://codegolf.meta.stackexchange.com/a/12708 > Unfortunately, I don't think TIO is a very reliable way of timing code, even if counting CPU time rather than wall time. > > First of all, TIO uses multiple arena servers, where all user-supplied code is run. At point, there are only two arenas and both have identical specs, but even now, one of them is consistently and considerably slower than the other. I have no idea why this happens, but it does. > > Also – and this applies to all method of timing code – two processes running at the same time can affect each other in subtle ways that will impact CPU time. E.g., speed of memory access may be affected, especially if the data should already be in the CPU's cache, but was pushed out by another process. Computers also tend to be measurably faster after a restart. > > Of course, running code on TIO is still better than having everyone time their code on their own machines. I wouldn't even consider the latter an objective winning criterion for a fastest-code challenge. Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.
guest271314 at gmail.com (2019-05-25T23:11:23.247Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be tested and compared? The same code being used at different computers; or different code used at the same computer? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset one primary limiting factor as to "how many" would probably be the available RAM and hard disk space of the computer used (and browser preferences, policies, configuration) to load the modules (before the browser/OS freezes), similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467 ; https://stackoverflow.com/questions/39959467#comment67315240_40017582) where the result can vary considerably when testing code on different computers, depending on available RAM and hard-disk space of the computer (for example, comparing results at a minimal OS at Raspberry Pi with 500MB of available RAM and the same OS having 16GB RAM; or a non-minimal OS with multiple applications and the browser running compared to only the browser application being running, etc.). The tentative answer to the original question "how many async-modules can js-app practically load?" would be until memory and available disk space runs out. Tests of such code should also include the hardware and software used for the test. Online tests of code can provide inaccurate results, see Is TIO acceptable for fastest-code questions? https://codegolf.meta.stackexchange.com/q/12707 ; https://codegolf.meta.stackexchange.com/a/12708 > Unfortunately, I don't think TIO is a very reliable way of timing code, even if counting CPU time rather than wall time. > > First of all, TIO uses multiple arena servers, where all user-supplied code is run. At point, there are only two arenas and both have identical specs, but even now, one of them is consistently and considerably slower than the other. I have no idea why this happens, but it does. > > Also – and this applies to all method of timing code – two processes running at the same time can affect each other in subtle ways that will impact CPU time. E.g., speed of memory access may be affected, especially if the data should already be in the CPU's cache, but was pushed out by another process. Computers also tend to be measurably faster after a restart. > > Of course, running code on TIO is still better than having everyone time their code on their own machines. I wouldn't even consider the latter an objective winning criterion for a fastest-code challenge. Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.
guest271314 at gmail.com (2019-05-25T22:54:48.540Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be tested and compared? The same code being used at different computers; or different code used at the same computer? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset one primary limiting factor as to "how many" would probably be the available RAM and hard disk space of the computer used (and browser preferences, policies, configuration) to load the modules (before the browser/OS freezes), similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467 ; https://stackoverflow.com/questions/39959467#comment67315240_40017582) where the result can vary considerably when testing code on different computers, depending on available RAM and hard-disk space of the computer (for example, comparing results at a minimal OS at Raspberry Pi with 500MB of available RAM and the same OS having 16GB RAM; or a non-minimal OS with multiple applications and the browser running compared to only the browser application being running, etc.). The tentative answer to the original question "how many async-modules can js-app practically load?" would be until memory and available disk space runs out. Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.
guest271314 at gmail.com (2019-05-25T22:53:06.271Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be tested and compared? The same code being used at different computers; or different code used at the same computer? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset one primary limiting factor as to "how many" would probably be the available RAM and hard disk space of the computer used (and browser preferences, policies, configuration) to load the modules (before the browser/OS freezes), similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467 ; https://stackoverflow.com/questions/39959467#comment67315240_40017582) where the result can vary considerably when testing code on different computers, depending on available RAM and hard-disk space of the computer (for example, comparing results at a minimal OS at Raspberry Pi with 500MB of available RAM and the same OS having 16GB RAM; or a non-minimal OS with multiple applications and the browser running compared to only the browser application being running, etc.). Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.
guest271314 at gmail.com (2019-05-25T22:50:01.645Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be tested and compared? The same code being used at different computers; or different code used at the same computer? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset one primary limiting factor as to "how many" would probably be the available RAM and hard disk space of the computer used (and browser preferences, policies, configuration) to load the modules (before the browser/OS freezes), similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467 ; https://stackoverflow.com/questions/39959467#comment67315240_40017582) where the result can vary considerably when testing code on different computers, depending on available RAM and hard-disk space of the computer (for example, comparing results at a minimal OS at Raspberry Pi with 500MB of available RAM and the same OS having 16GB RAM; or a non-minimal OS with multiple applications running compared to only the browser running without multiple applications running, etc.). Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.
guest271314 at gmail.com (2019-05-25T22:48:16.718Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be tested and compared? The same code being used at different computers; or different code used at the same computer? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset one primary limiting factor as to "how many" would probably be the available RAM and hard disk space of the computer used (and browser preferences, policies, configuration) to load the modules (before the browser/OS freezes), similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467 ; https://stackoverflow.com/questions/39959467#comment67315240_40017582) where the result can vary considerably when testing code on different computers, depending on available RAM and hard-disk space of the computer (for example, comparing results at a minimal OS at Raspberry Pi with 500MB of available RAM and same OS having 16GB RAM). Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.
guest271314 at gmail.com (2019-05-25T22:42:31.622Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be tested and compared? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset one primary limiting factor as to "how many" would probably be the available RAM and hard disk space of the computer used (and browser preferences, policies, configuration) to load the modules (before the browser/OS freezes), similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467 ; https://stackoverflow.com/questions/39959467#comment67315240_40017582) where the result can vary considerably when testing code on different computers, depending on available RAM and hard-disk space of the computer. Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.
guest271314 at gmail.com (2019-05-25T22:13:16.541Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be tested and compared? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset the presumptive answer would probably be the available RAM and hard disk space of the computer used (and browser preferences, policies, configuration) to load the modules (before the browser/OS freezes), similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467 ; https://stackoverflow.com/questions/39959467#comment67315240_40017582) where the result can vary considerably when testing code on different computers, depending on available RAM and hard-disk space of the computer. Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.
guest271314 at gmail.com (2019-05-25T22:11:59.319Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be tested and compared? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset the presumptive answer would probably be the available RAM and hard disk space of the computer used (and browser preferences, policies, configuration) to load the modules (before the browser/OS freezes), similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467; https://stackoverflow.com/questions/39959467#comment67315240_40017582) where the result can vary considerably when testing code on different computers, depending on available RAM and hard-disk space of the computer. Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.
guest271314 at gmail.com (2019-05-25T22:10:12.132Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be tested and compared? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset the presumptive answer would probably be the available RAM and hard disk space of the computer used (and browser preferences, policies, configuration) to load the modules (before the browser/OS freezes), similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467) where the result can vary considerably when testing code on different computers, depending on available RAM and hard-disk space of the computer. Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.
guest271314 at gmail.com (2019-05-25T22:09:40.719Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be tested and compared? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset the presumptive answer would probably be the available RAM and hard disk space of the computer used (and browser preferences, policies, configuration) to load the modules (before the browser/OS freezes), similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467) where the result can vary considerably when testing code on different devices, depending on available RAM and hard-disk space of the device. Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.
guest271314 at gmail.com (2019-05-25T22:08:51.333Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be compared? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset the presumptive answer would probably be the available RAM and hard disk space of the computer used (and browser preferences, policies, configuration) to load the modules (before the browser/OS freezes), similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467) where the result can vary considerably when testing code on different devices, depending on available RAM and hard-disk space of the device. Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.
guest271314 at gmail.com (2019-05-25T22:07:24.464Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be compared? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset the presumptive answer would probably be the available RAM and hard disk space of the computer used (and browser preferences, policies, configuration) to load the modules, similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467) where the result can vary considerably when testing code on different devices, depending on available RAM and hard-disk space of the device. Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.
guest271314 at gmail.com (2019-05-25T22:06:39.357Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be compared? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset the presumptive answer would probably be the available RAM and hard disk space of the computer used (and browser preferences, policies, configuration) to load the modules, similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467) where the result can vary considerably when testing code on using devices depending on available RAM and hard-disk space. Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.
guest271314 at gmail.com (2019-05-25T22:05:15.047Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be compared? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset the presumptive answer would probably be the available RAM and hard disk space of the computer used (and browser preferences, policies, configuration) to load the modules, similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467) where the result is can be vary considerably when testing code on using devices having different available RAM and hard-disk space. Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.
guest271314 at gmail.com (2019-05-25T22:04:34.082Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be compared? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset the presumptive answer would probably be the available RAM and hard disk space of the computer used (and browser preferences, policies, configuration) to load the modules, similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used (e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467) where the result is can be vary vastly when using devices having different available RAM and hard-disk space. Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.
guest271314 at gmail.com (2019-05-25T22:03:58.536Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be compared? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? From the outset the presumptive answer would probably be the available RAM and hard disk space of the computer used (and browser preferences, policies, configuration) to load the modules, similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used; e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467 where the result is can be vary vastly when using devices having different available RAM and hard-disk space. Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.
guest271314 at gmail.com (2019-05-25T22:03:21.482Z)
> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be compared? What are you trying to determine? The current question asks > how many async-modules can js-app practically load? which leads to asking how many async-modules are actually needed? >From the outset the presumptive answer would probably be the available RAM and hard disk space of the computer used (and browser preferences, policies, configuration) to load the modules, similar to asking the maximum content-length of a file which can be fetched and downloaded and the length of time such a procedure takes in the browser, which depends on the available RAM and hard-disk space of the computer(s) used; e.g., see How to solve Uncaught RangeError when download large size json https://stackoverflow.com/q/39959467 where the result is can be vary vastly when using devices having different available RAM and hard-disk space. Again, have not tried babel or webpack for the purpose of loading modules. Normally try to use only code that is shipped with FOSS browsers, when the code is being used in the browser, where possible.