| 215 | | For 1 and 3, the performance impact appears negligible and some bugs will be fixed, so we would suggest that the answer should be yes. |
| | 219 | For 1 and 3, the performance impact appears negligible (or perhaps even negative) and some bugs will be fixed, so we would suggest that the answer should be yes. |
| | 220 | |
| | 221 | For 2 and 4, there would be a considerable performance impact, but there is again a negligible impact if you instead switch to using x86_64. We believe that this would be feasible for the vast majority of users for whom performance is a concern, and it would greatly simplify the code base, so again we would suggest that the answer should be yes. |
| | 222 | |
| | 223 | For 5 and 6, we will first have to get it working. Windows already uses different code paths quite a lot, so even if we end up deciding not to go dynamic-by-default on Windows, a lot of the ugly, buggy code will be removed. However, there are some known bugs in it on Windows, so we are hopeful that we will be able to do dynamic-by-default here too. |
| | 224 | |
| | 225 | For 7, this makes the difference between being able to use ghci and not being able to use ghci, and performance is already compromised for unregisterised platforms. Therefore this looks like a definite yes. |
| | 226 | |
| | 227 | For 8, this is a trade-off between the convenience of always having static libraries available (which may be important for people for whom performance is critical), and doubling the time needed to install extra libraries. On balance, we'd suggest that the answer should be no. If we go for yes, then we'd probably want a little extra intelligence in cabal, which checks that e.g. there is a static version of base installed before trying to install the static way, as development compilers in particular may only be built with the dynamic libraries available. |
