<div dir="ltr">Basically I understand what's going on (especially from Instruments), but question is not about implementation.<div>I'm speaking about UNIFORM behaviour for all platform (actually I guess we will see Windows/Android and so on ports).<div>So Array on Linux should work as Array on OSX, Windows, Android, ....</div></div><div>If we need specific OS behaviour we should make specific class like ObjcArray<Class>, .... Isn't it right way ?</div><div>Or at least in language guide should be written "Use Array only if you need to interact with ObjC runtime..." and of course same about all other ObjC classes. Right ?</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 30, 2016 at 5:55 AM, Joe Groff <span dir="ltr"><<a href="mailto:jgroff@apple.com" target="_blank">jgroff@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Jan 29, 2016, at 11:32 AM, Trent Nadeau <<a href="mailto:tanadeau@gmail.com">tanadeau@gmail.com</a>> wrote:<br>
><br>
> I haven't looked at the bridging code yet, but is it possible that the overhead could only be incurred on the first conversion to NSArray? That way if you don't use that functionality it's consistent across platforms, and if you do use it, you get an initial O(n) hit and then O(1) afterwards.<br>
<br>
</span>Dave Abrahams can probably elaborate on the history better than me, but the current design balances a number of considerations. Microbenchmarks tend to be poor indicators of real-world performance, and in most Cocoa application code, arrays are shuttled into and out of Cocoa pretty frequently, so forcing every index read operation to do a deep conversion was unacceptable.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Joe</font></span></blockquote></div><br></div>