> -O (Fast)
>
> plain for loop with guard
> Elapsed time: 0.00411999225616455
> plain for loop with if
> Elapsed time: 0.00422400236129761
> where test
> Elapsed time: 0.00419700145721436
> eager filter test
> Elapsed time: 0.033439040184021
> lazy filter test
> Elapsed time: 0.00690501928329468
> Program ended with exit code: 0
>
> Code:
>
> public func timetest(_ note: String, block: () -> Void) { > let date =
> NSDate() > block()
> let timeInterval = NSDate().timeIntervalSince(date)
> print(note); print("Elapsed time: \(timeInterval)")
> }
>
> let count = 4_000_000 > let range = 1...count
>
> timetest("plain for loop with guard") {
So this is what we are taking about...
Regards
(From mobile)
> On Jun 14, 2016, at 7:01 AM, Charlie Monroe <char...@charliemonroe.net> wrote:
>
>
>> On Jun 13, 2016, at 9:59 PM, Brent Royal-Gordon <br...@architechies.com>
>> wrote:
>>
>>>> See the benchmarks me and Erica have posted here a few days back - even
>>>> with the lazy accessor, if you decided to use filter(_:), you lost 10+% of
>>>> performance. Correct way to do this without `where` and without
>>>> performance penalization is to use guard within the for-in loop.
>>>
>>> 10% on a microbenchmark repeater 4000000 times is hardly a justification
>>> for going on way or the other.
>>
>> You're right: 10% on a microbenchmark isn't the best possible data. If you
>> have better data, we are all ears.
>
> I never said that it's a deal-breaker, but it is definitely something to
> consider. Since we're discussing performance of the loop itself, you can't
> perform much in the body of the for loop since it would skew the result
> (obviously).
I used to do low latency java for trading systems... the kind of coding where
we would go out of our way to avoid ANY intraday gc activity (yes it can be
done, even for parsing xml files). So we cared about a lot of things... But
when you look at the numbers above on a 4_000_000 iterations loop and say the
differential matters? I say you are probably using the wrong tools to write
your code in the first place, and you should be using accelerate.
As for the '
>
> I've previously noted that if/guard-continue come in really close speed-wise,
> which makes them candidates for a fix-it in case `where` is indeed removed.
>
> My response here was solely to Jean-Daniel's note that he mustn't forget to
> include the lazy accessor, pointing out that even the lazy accessor is slower
> than using an inline check.
>
>
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
