7 ms·
On Performant Arrays in Swift
- dep_b 9y agoVery fascinating stuff, also follow the link at the bottom of the article towards another explanation with visuals how arrays are structured. Honestly I never run into performance problems since the volume of data I work with is either really huge and done in a C or C++-based library or so small I would never think about array performance.
- valuearb 9y agoAlmost always, worrying about arrays is premature optimization.
- whowouldathunk 9y agoOn the contrary, developing a good intuition about stuff like this so you get it right the first time is a big time saver in the long run. Especially when it's no extra code to do the better thing to begin with. Good developers have battery empathy.
- pjmlp 9y agoGood developers know when to use profilers.
- jcelerier 9y agothanks for your contribution to my job safety :p
- tzahola 9y agoWhy does every Swift article use emojis in their code samples?
- ovao 9y agoI imagine because Swift famously touted the ability to use emojis as identifiers.
- jmull 9y agoReading these things makes me hungry. I think it’s because that’s the style of Apple’s own (excellent) Swift Programming Language book. I think it does look nicer than the traditional characters used in these kinds of things.
- proyb 9y agoEasy, our mobile devices screen width is limited. Emoji is the idea and it make learning not boring.
- drak0n1c 9y agoThe language supports emojis, and the point of example code is to be as concise and easy to understand as possible. Better than foobar.
- waynecochran 9y agoOptimization makes a huge difference with arrays in Swift. The following took 2.37 seconds (!) on my machine un-optimized: var bytes = [UInt8](count: 16_737_732, reapeatedValue: 0) This was slow enough to block my UI (spinning pizza) -- so I ran it on a background thead!. Turn on optimization and it took a more reasonable 0.0165 seconds. BTW, took C's memset only 0.00827 seconds on the same machine. I switched back to my beloved Objective-C for the app I was developing. Won't be using Swift for low-level image processing.
- bluedino 9y ago>> I switched back to my beloved Objective-C for the app I was developing. Can you write the app in Swift (if there are advantages to doing so) and then write the image processing routines/library in C?
- waynecochran 9y agoYes, but I hate figuring out the bridging stuff when I can just use C directly in Objective-C.
- adamnemecek 9y agoThe bridging is pretty straight forward no? You add a bridging header and put in all the headers you want to expose to swift and you are good to go.
- waynecochran 9y agoPretty straight forward, but there is zero friction when using Obj-C.
- tentaTherapist 9y agoYou say 'beloved Objective-C'. Sorry if this is really off topic, but is objc_msgsend (the whole late-binding thing) or anything else about Objective-C particularly appealing? Maybe the decent unoptimized speeds or the fact that you can use plain C whenever?
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]
- Someone 9y agoThis article says ”Array can be toll-free bridged to an NSArray”, but is the reverse true, too? https://developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/WorkingWithCocoaDataTypes.html https://developer.apple.com/library/content/documentation/Sw... says the two are bridged, but doesn’t mention whether that is toll-free. If that is toll-free, users of Array, just as users of NSArray, should be aware that indexing in them can be O(log n). See http://ridiculousfish.com/blog/posts/array.html http://ridiculousfish.com/blog/posts/array.html