> Currently the compiler does not do the kind of optimization you > describe. A function is compiled once, and computes all of its > results. The caller receives all the results, and ignores ones that > it does not need. >
yes, i suppose the code generation route might give some insight as to if this might be worth it, but you probably have to code to it and so the results wouldn't then clearly differentiate. > We could implement the general optimization by compiling a function > multiple times, for each permutation of the possible results. i feel it might not be that bad; you only need the permutations that are actually being used and the feeling i have is that a given problem, and so a given program, will tend to only use a small selected subset of permutations. > But I think it's clear that that effort would generally be wasted. So we > would need some way to decide when this optimization would be useful. > And note that any effort in this area would tend to go against the > overall goal of fast compilation time. > given above is correct you could probably just limit the number. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b823a6b2-f027-416c-9464-664e5df05561o%40googlegroups.com.
