Re: The Swift Programming Language: what is our position towards this?

[Lundberg, Johannes]

Yeah I also think 40% more efficient sounds strange.. Most be some extreme case or part of app.. If so, then why not only turn off ARC for that .m file or write that part in C?...

--

Johannes Lundberg

BRILLIANTSERVICE CO., LTD.

On Mon, Jun 9, 2014 at 10:23 PM, David Chisnall <David.Chisnall@cl.cam.ac.uk> wrote:

On 9 Jun 2014, at 13:46, Riccardo Mottola <riccardo.mottola@libero.it> wrote:

> The same guys write also:
>
>> For example, we don’t use – surprise! – Automatic Reference Counting at Splasm because, frankly, it’s around 40% slower in some cases, so we’ll leave ARC off and take that 40% back (and we enjoy manual memory management, thank you very much).  Other teams wouldn’t give up ARC even if paint dried faster.  Did I say ‘if’?  Different teams.  Different values.

I think that's all you need to read to know not to take his opinions about performance seriously.  Except in some pretty contrived examples, ARC is a big win for performance.  It's fairly easy to put together a microbenchmark where it does worse: just put things in the autorelease pool early on and forget to drain the pool.  On both OS X and GNUstep, ARC and non-ARC retains and releases use the same mechanism, but without ARC you get an extra message send on each one.  If you're able to elide enough reference count operations to offset this, then it's possible to be faster, but it's also incredibly likely that you'll introduce some subtle bugs.

And, honestly, if you're willing to give up that convenience for that little performance (40% over an entire app?  Not a chance.) then why not write in pure C?

David

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.