4 ms·
Wait, what? 50 milliseconds per line of code? How is that even possible?
by fdej 8y ago
Wait, what? 50 milliseconds per line of code? How is that even possible?
- abecedarius 8y agoNot 50 milliseconds, 5 microseconds. Something like 10,000 cycles, or a few hundred to a thousand cycles per byte of source code (depending on average line length).
- fdej 8y ago"around 20. Not K, just lines/sec"
- abecedarius 8y agoSorry for the misunderstanding. Inefficiencies on that level just aren't very surprising to me anymore.
- opencl 8y agoIt is heavily dependent on the type of code you write. For example, ternary operators can take several hundreds of milliseconds or even entire seconds each to compile while an equivalent if statement is orders of magnitude faster[1]. Anything with type inference also tends to compile very slowly. [1] https://bugs.swift.org/browse/SR-1577 https://bugs.swift.org/browse/SR-1577
- mpweiher 8y agoMakes you wonder, right? Of course, there are (still) pathological cases where a single line of code will abort because it runs out of time. > cat too-complex.swift let a:[Int] = [1] + [2] + [3] + [4] + [5] + [6] + [7] For me, this aborts after about a minute and a half: > time swiftc too-complex.swift too-complex.swift:1:49: error: expression was too complex to be solved in reasonable time; consider breaking up the expression into distinct sub-expressions let a:[Int] = [1] + [2] + [3] + [4] + [5] + [6] + [7] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~ real 1m35.094s user 1m16.698s sys 0m5.141s That appears to be some sort of exponential in type inference. Other similar ones have been fixed. The ternary expressions mentioned elsewhere also appear to be problematic, and in general, there's little time bombs all over just waiting to go off. The rate I mentioned earlier was taken from a CocoaHeads talk by someone who built a caching mechanism for Carthage, because their Swift framework(s) of around 20KLOC were taking ages to compile. So it's a real-world example, not something made up.
- munificent 8y ago> That appears to be some sort of exponential in type inference. If I recall, it's in the implicit conversions, not strictly the type inference.