Michael Tsai
@nuoji Yes, agreed about the perf being more hidden. I thought you were talking about "explicit" when reading the code.
-
@mjtsai require additional patches for every special case.
Christoffer Lernö
@mjtsai compare ObjC where there aren't all that many places where you can optimize.
-
-
@mjtsai perf is slower than swift in the fastest case, but it is consistent, where Swift easily can differ several orders of magnitude. - View other replies
-
@nuoji Seems like you have to hope that the compiler never regresses and also that you can figure out what it's doing in pathological cases. -
@mjtsai "Seems like you have to hope that the compiler never regresses" exactly. You need to put your faith in the optimizer. That is scary. -
@nuoji Incidentally, this also means that a hypothetical second implementation of the language would need to do all the same optimizations… -
@mjtsai Yes that too.
-
-
@mjtsai works superfast under conditions x and y, and then is slow as hell when used with z where something breaks optimization. -
@mjtsai Swift will always have a huge diff between best case (full inline) and worst case. This can cause perf traps: -
@nuoji I guess this is what happens when you move functionality from the libraries into the language.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.