Soru Düşük seviyeli kod için Objective-C kullanırsam, iPhone uygulamam performansa dönüşür mü?


İPhone veya diğer taşınabilir donanım üzerinde yoğun veya GPU yoğun bir uygulama programlarken, kodunuzu hızlı hale getirmek için akıllı algoritmik kararlar vermeniz gerekir.

Ancak kullandığınız dil, diğerinden daha kötü performans gösteriyorsa, harika algoritma seçenekleri bile yavaş olabilir.

Objektif-C ile C ++ arasında, özellikle de iPhone'da, ancak Mac masaüstünde, benzer dil yönlerinin performansında, herhangi bir zor veri var mı? Çok tanıdık C ve Objective-C'yi karşılaştıran bu makaleama bu, iki nesne yönelimli dili birbiriyle karşılaştırmanın daha büyük bir sorusu.

Örneğin, bir Obj-C mesajından çok daha hızlı bir C ++ vtable araması mı? Ne kadar hızlı? Threading, polymorphism, sorting, vs. Yinelenen nesne modelleri ve çeşitli test kodları ile bir proje oluşturmak için bir arayışa başlamadan önce, kimsenin bunu yapıp yapmadığını ve sonuçların nerede olduğunu bilmek istiyorum. Bu tür bir test ve karşılaştırma, kendi başına bir projedir ve önemli miktarda zaman alabilir. Belki bu bir proje değildir, ancak iki ve sadece çıktılar karşılaştırılabilir.

Arıyorum zor verievangelizm değil. Birçoğunuz gibi çeşitli nedenlerle her iki dili de seviyorum ve nefret ediyorum. Dahası, eğer aynı şeyi aktif olarak yürüten biri varsa, sonuçların sonucunu görmek için bazı kodlarda dikkat çekmek istiyorum ve eminim başkaları da yardım edebilir. Benim tahminim onların hem güçlü hem de zayıf yönleri olması, amacım gerçek dünyadaki senaryolarda kaçınılmaları / sömürülmeleri için tam olarak ne olduklarını bulmaktır.


68
2018-05-29 15:53


Menşei


Sorunun arkasındaki nokta nedir? Bir iPhone projesi yazmadan önce öğrenmek için bir dil seçiyor musunuz? Diğer projelerde kullanacağınız bir dili öğrenmek mi istiyorsunuz? - Rog
Ekibimiz zaten hem obj-c hem de c ++ biliyor. İki arasındaki benzer işlemlerin karşılaştırmasını arıyorum. Önemli olan bu bilgi uygulanabilir. Hızlı bir numaralandırma yerine bir stl yineleyici kullanmak gibi bir şey, zamanın bir problemi farklı şekilde ele almamıza neden olabileceğini bilerek,> 10000 maddelik listelerde büyük bir fark yaratır. - slf
Yoğun operasyonlar için düz taşınabilir statik C fonksiyonu çağrılarını kullanabilirsiniz.


Cevaplar:


Mike Ash, görevine C ve C ++ karşı çeşitli Objective-C yöntem çağrılarının performansı için bazı zor sayılara sahiptir. "Ortak Operasyonların Performans Karşılaştırmaları". Ayrıca, bu gönderi   Objective-C ++ kullanarak bir iPhone uygulamasının performansını ayarlama geldiğinde Savoy Software tarafından ilginç bir okuma.

Objective-C'nin Objective-C'nin temiz, açıklayıcı sözdizimini tercih etme eğilimindeyim ve performans darboğazlarımın kaynağı olarak dilin kendisini bulamadı. Kodumu çok daha fazla korunabilir yaparlarsa, birazcık performanstan fedakarlık ettiğim şeyler yapmaya bile eğilimliyim.


57
2018-05-30 00:45



Mükemmel nokta. Kayıt için şu anda herhangi bir performans darboğazımız yok ya da ObjC’deki şeyleri suçluyoruz, tam tersi. Günün sonunda sanırım bu soru sadece bilimsel gerçekler için şehvetimi tatmin etmektir. - slf
harika bağlantılar için kazmak - slf
DURDURMAK. "Performans Karşılaştırmaları" inanılmaz derecede kötüdür. bir 'performans karşılaştırması' Amaç-C'yi karşılaştırmak için bir şey olmalı için: Düz C ve C ++. Bu bir karşılaştırma değil. Bu, ortak operasyonlar için tamamen anlamsız çalışmaların bir listesidir (tamamen anlamsızdır, çünkü bazı elemanların özel donanımları üzerinde kurulmaktadır). - bobobobo
İkinci makale, dizilerle çalışırken, 4x performansım olduğunu söyledi. artırma C-dizilerine geçerek ". Çelişki. Makale, maksimum performans için C'yi kullanmanız gerektiğini söylüyor, ama cevabınız" Eah sadece C nesnesini kullan "diyor - bobobobo
@bobobobo - İŞBİRLİĞİ VE DİNLENME. Cidden, Mike'ın kriterleriyle ilgili probleminizi anlamıyorum. Ortak düşük seviyeli operasyonlar yürüttü ve onları C nesnesindeki Objective-C katmanları, yani mesaj gönderme, nesne tahsisi / serbest bırakma ve benzeri ile karşılaştırdı. Hepsi tek bir donanım parçası üzerinde çalışıyorlardı ve göreceli önlemler. Donanımınızda çalışabilmeniz için ölçütleri kullanılabilir hale getirdi ve benzer cihazlarla benzer sonuçlar elde etti. Kendi ölçütünüze işlev çağrısı, C ++ nesne ayırma, vb. Eklemek istiyorsunuz, bunu yapmaktan çekinmeyin. - Brad Larson♦


Evet, iyi yazılmış C ++ çok daha hızlı. Performansla ilgili kritik programlar yazıyorsanız ve C ++'nuz C kadar hızlı değilse (veya birkaç yüzde içinde), bir şeyler yanlıştır. ObjC uygulamanız C kadar hızlı ise, o zaman genellikle yanlış - yani program muhtemelen ObjC OOD'un kötü bir örneğidir, çünkü doğrudan ivar erişimleri gibi içinde çalıştığı soyutlama katmanının altına adım atmak için bazı 'kirli' püf noktaları kullanır.

Mike Ash 'karşılaştırma' çok yanıltıcıdır - Yazdığınız programların yürütme zamanlarını karşılaştırmak için yaklaşımı tavsiye etmem ya da C vs C ++ vs ObjC'yi karşılaştırmanızı tavsiye etmem. Sunulan sonuçlar derleyici optimizasyonları ile bir testten sağlanmıştır. engelli. Yürütme sürelerini ölçerken, en iyi duruma getirme seçenekleri ile derlenmiş bir program nadiren geçerlidir. C ++ ile Objective-C'yi karşılaştıran bir kıyaslama olarak görmek için kusurludur. Bu test ayrıca, gerçek dünyadaki en iyi duruma getirilmiş uygulamalar yerine bireysel özellikleri karşılaştırır - bireysel özellikler her iki dil ile de çok farklı şekillerde birleştirilir. Bu, optimize edilmiş uygulamalar için gerçekçi bir performans ölçütünden çok uzaktır. Örnekler: Optimizasyonlarla etkin, IMP önbellek sanal işlev çağrıları kadar yavaş. Statik gönderim (örneğin, dinamik dağıtımın aksine) virtual) ve bilinen C ++ türlerine (dinamik gönderimin atlanabileceği) çağrıları agresif bir şekilde optimize edilebilir. Bu sürece devirtualization denir ve kullanıldığı zaman, ilan edilen bir üye işlevi virtual hatta olabilir inlined. Bildirilen üye fonksiyonlarına birçok çağrının yapıldığı Mike Ash testinde virtual ve boş organlar var: bu çağrılar en uygun hale getirildi Baştan sona Derleyici uygulaması gördüğü ve dinamik dağıtımı belirleyebildiği için tür biliniyorsa gereksizdir. Derleyici ayrıca çağrıları da kaldırabilir malloc optimize edilmiş yapılarda (yığın depolamayı destekleyerek). Bu nedenle, C, C ++ veya Objective-C'nin herhangi birinde derleyici optimizasyonlarını etkinleştirmek, yürütme sürelerinde önemli farklılıklar oluşturabilir.

Bu, sunulan sonuçların tamamen işe yaramaz olduğunu söylemez. Harcadıkları zamanlar arasında ölçülebilir farklılıklar olup olmadığını belirlemek isterseniz, harici API'lerle ilgili bazı yararlı bilgiler edinebilirsiniz. pthread_create veya +[NSObject alloc] Bir platform veya mimariye karşı diğerine. Elbette, bu iki örnek testinizde optimize edilmiş uygulamaları kullanacaktır (bunları geliştirmediğiniz sürece). Ancak, bir dilde karşılaştırdığınız programlarda bir dil karşılaştırmak için… sunulan sonuçlar, optimizasyonlar devre dışıyken kullanılamaz.

Nesne Oluşturma

ObjC'de nesne oluşturmayı da düşünün - her nesne dinamik olarak (ör. Yığınta) ayrılır. C ++ ile, yığın üzerinde nesneler oluşturulabilir (ör., Bir C yapısını oluşturma ve birçok durumda basit bir işlevi çağıran kadar hızlı), yığında veya soyut veri türlerinin öğeleri olarak. Her ayırdığınız ve serbest bıraktığınızda (örneğin malloc / free), bir kilidi tanıtabilirsiniz. Yığında C struct veya C ++ nesnesi oluşturduğunuzda, hiçbir kilitleme gerekmez (iç üyeler yığın ayırmalarını kullanabilirler) ve genellikle yalnızca birkaç yönerge veya birkaç yönerge artı işlev çağrısı gerektirir.

Ayrıca ObjC nesneleri referans sayılan örneklerdir. Bir nesnenin gerçek ihtiyacı std::shared_ptr performans kritik C ++ çok nadirdir. Her örneği paylaşılan, referans sayılan bir örnek haline getirmek C ++ 'da gerekli veya istenmeyebilir. C ++ ile sahiplik ve ömür boyu daha fazla kontrolünüz var.

Diziler ve Koleksiyonlar

Diziler ve C ve C ++'daki birçok koleksiyon da güçlü yazılan kaplar ve bitişik bellek kullanır. Bir sonraki elemanın üyelerinin sık sık bilindiğinden, optimize edici çok daha fazlasını yapabilir ve harika bir önbellek ve hafıza konumuna sahip olursunuz. ObjC ile, standart nesneler için gerçeklikten uzaktır (ör. NSObject).

Sevk etmek

Yöntemler ile ilgili olarak, birçok C ++ uygulaması, özellikle yüksek düzeyde optimize edilmiş programlarda, birkaç sanal / dinamik çağrı kullanır. Bunlar, iyileştiriciler için statik yöntem çağrıları ve yemleridir.

ObjC yöntemleri ile, her yöntem çağrısı (objc mesaj gönderimi) dinamiktir ve sonuç olarak optimizer için bir güvenlik duvarıdır. Sonuç olarak, bu, performans açısından kritik ObjC yazarken performansı minimumda tutmak için yapabileceğiniz ve yapamayacağınız şeylerle ilgili birçok kısıtlama veya sakıncaya yol açar. Bu, daha büyük yöntemler, IMP önbelleğe alma, C sık kullanımı ile sonuçlanabilir.

Bazı gerçek zamanlı uygulamalar kullanamaz herhangi ObjC mesajları render yollarında. Yok - ses işleme bunun iyi bir örneğidir. ObjC gönderimi, gerçek zamanlı amaçlar için tasarlanmamıştır; Nesneleri mesajlaşırken, nesnelerin mesajlaşmasının ve karmaşıklıkların karmaşıklığını / zamanını, ses yorumunun son tarihini kaçırabilecek kadar önceden tahmin edilemez hale getirdiği durumlarda sahnelerin arkasından gerçekleşebilir.

Diğer özellikler

C ++ ayrıca kütüphanelerinin birçoğu için jenerik / şablon uygulamaları sağlar. Bunlar çok iyi optimize edilir. Bunlar, güvenlidir ve şablonlarla çok sayıda inline ve optimizasyon yapılabilir (derleme sırasında gerçekleşen polimorfizm, optimizasyon ve uzmanlaşma düşünün). C ++, sadece mevcut olmayan veya sıkı ObjC ile karşılaştırılabilir olmayan birkaç özellik ekler. Çok farklı olan şeritleri, nesneleri ve kütüphaneleri doğrudan karşılaştırmaya çalışmak çok yararlı değildir - gerçek gerçekleşmelerin çok küçük bir alt kümesidir. Tasarımın ve uygulamanın birçok yönünü göz önünde bulundurarak soruyu bir kütüphane / çerçeve veya gerçek bir programa genişletmek daha iyidir.

Diğer puan

C ve C ++ sembolleri, yapının çeşitli aşamalarında daha kolay kaldırılabilir ve optimize edilebilir (sıyırma, ölü kodların ortadan kaldırılması, satır içi ve erken hizalama, ayrıca Bağlantı Süresi Optimizasyonu). Bunun avantajları arasında ikili ikili boyutlar, azaltılmış başlatma / yükleme süreleri, azaltılmış bellek tüketimi, vb. Bulunur. Tek bir uygulama için bu çok büyük bir sorun olmayabilir; fakat çok fazla kodu tekrar kullanırsanız ve yapmanız gerekirse, o zaman ortak bir kütüphane, ObjC uygulanmışsa, programa gereksiz bir ağırlık ekleyebilir - bazı ateşli çemberler atlamak için hazır değilseniz. Ölçeklenebilirlik ve yeniden kullanım aynı zamanda orta / büyük projelerde ve yeniden kullanımın yüksek olduğu gruplarda da faktörlerdir.

Dahil Kütüphaneler

ObjC kütüphane uygulayıcıları ayrıca çevre için optimize ederler, bu yüzden kütüphane uygulayıcıları en iyi duruma getirilmiş uygulamaları sunmak için bazı dil ve ortam özelliklerini kullanabilirler. Saf ObjC'de optimize edilmiş bir program yazarken bazı önemli kısıtlamalar olsa da, Kakao'da bazı yüksek düzeyde optimize edilmiş uygulamalar bulunmaktadır. Bu, Kakao'nun güçlü noktalarından bir tanesidir, ancak C ++ standart kütüphanesi (bazı kişilerin STL olarak adlandırdığı) hiçbir kese değildir. Kakao, C ++ 'dan çok daha yüksek bir soyutlama seviyesinde çalışır - eğer ne yaptığınızı (ya da yapmanız gerektiğini) iyi bilmiyorsanız, metale daha yakın çalışmak gerçekten sana mal olabilir. Öğrenmeye gerçekten hazır olmadıkça, bazı alanlarda uzman değilseniz iyi bir kütüphane uygulamasına geri dönmek iyi bir şeydir. Ayrıca, Cocoa'nın ortamları sınırlıdır; İşletim Sistemini daha iyi kullanan uygulamalar / optimizasyonlar bulabilirsiniz.

En iyi duruma getirilmiş programlar yazıyorsanız ve hem C ++ hem de ObjC'de bunu yaparak deneyimliyseniz, temiz C ++ uygulamaları genellikle iki kat daha hızlı veya daha hızlı olacaktır. temiz ObjC (evet, kakao ile karşılaştırabilirsiniz). Nasıl optimize edeceğinizi biliyorsanız, genellikle daha yüksek seviyeli genel amaçlı soyutlamalardan daha iyisini yapabilirsiniz. Bazı optimize C ++ uygulamaları, Cocoa'dan daha hızlı veya daha yavaş olsa da (örneğin, C ++ uygulaması öncelikle belleğini başlattığı için dosya I / O'daki ilk denemem Kaka'dan daha yavaştı).

Birçoğu aşina olduğunuz dil özelliklerine geliyor. Her iki kurşunu da kullanırım, her ikisinin de farklı güçlü ve model / desenleri vardır. Birbirlerini oldukça iyi tamamlarlar ve her ikisi için de büyük kütüphaneler vardır. Karmaşık, performans kritik bir program uyguluyorsanız, C ++ 'nın özelliklerinin ve kitaplıklarının doğru kullanımı size çok daha fazla kontrol sunacak ve optimizasyon için önemli avantajlar sağlayacaktır, öyle ki, sağ ellerde, "birkaç kat daha hızlı", iyi bir varsayılan beklentidir ( her seferinde kazanmayı beklemeyin, ya da bir iş olmadan, ancak). Unutmayın, C ++ 'nın gerçekten bu noktaya ulaşmak için yeterince iyi olduğunu anlamak yıllar sürer.

Performans kritik yolların çoğunu C ++ olarak tutuyorum, fakat aynı zamanda ObjC'nin bazı problemler için çok iyi bir çözüm olduğunu ve bazı çok iyi kütüphanelerin mevcut olduğunu kabul ediyorum.


54
2018-04-10 21:27



+1 içgörü için teşekkürler - slf
Detaylı cevabınız için +1 Justin - Asad Khan


Bunun için "zor veriler" toplamak çok zor çünkü yanlış yönlendirmiyor.

Önerdiğiniz gibi özellik-özellik karşılaştırması yapmanın en büyük sorunu, iki dilin çok farklı kodlama stillerini teşvik etmesidir. Objective-C, tipik C ++ kullanımının statik olduğu, ördek yazarak dinamik bir dildir. Aynı nesne yönelimli mimari problemin C ++ veya Objective-C kullanarak çok farklı ideal çözümlere sahip olması muhtemeldir.

Duygularım (her iki dilde de çok fazla programladığım gibi, çoğunlukla büyük projelerde): Objective-C performansını en üst düzeye çıkarmak için, C'ye çok yakın yazılmalıdır. Oysa C ++ ile dilin çok daha fazla kullanılmasını sağlamak mümkündür. C'ye kıyasla herhangi bir performans cezası

Hangisi daha iyi? Bilmiyorum. Saf performans için C ++ daima kenara sahip olacaktır. Ancak Objective-C'nin OOP tarzı kesinlikle onun değerlerine sahiptir. Aklı başında bir mimariyi onunla tutmanın daha kolay olduğunu düşünüyorum.


31
2018-05-29 16:11



Performansı önemsediğim iPhone'da, Objective-C'yi yalnızca Objective-C'de bulunan API'lere erişmek için kullandığımı buluyorum. C'deki API'ler için C (OpenGL ES gibi) ve kendi kodum için kullanıyorum. Bağlantı noktası kullanabileceğimi düşündüğüm bir şey için C kullanmayı tercih ederim (Java tabanlı bir telefona ya da JavaScript'e). Objective-C'den başka bir şeye geçmek bana bir mide ağrısını veriyor. - Nosredna
Gerçekten 'daha iyi' aramıyorum, ama anladım. Yine de, "c ++ daha hızlı" diye çığlık atan ofisin etrafında yürürken onu yedeklemek için bazı rakamlara sahip olmak beni daha az bir evanjist ve daha çok bir pragmatist gibi gösteriyor. - slf
Anlıyorum. Ofiste bir etki yaratmak için en iyi fikrin, uygulamanızdan bazı tipik kodları seçmek olacağını düşünüyorum. Bu, büyük olasılıkla çok zaman alacaktır. Bir C ++ ve bir Objective-C sürümü yazın. Ölç, karşılaştır, tartış. - Johan Kotlinski


Bu gerçekten, dil özelliklerini nasıl kullandığınıza bağlı olduğundan genel olarak yanıtlanabilecek bir şey değil. Her iki dil de hızlı oldukları şeylere, yavaş oldukları şeylere ve bazen hızlı ve bazen yavaş olan şeylere sahip olacaklar. Gerçekten ne kullandığınıza ve nasıl kullandığınıza bağlı. Kesin olmanın tek yolu, kodunuzu takip etmektir.

Objective C'de c ++ kodu da yazabilirsiniz, bu yüzden Objective C'de kod yazmak daha kolay olabilir ve eğer iyi performans göstermeyen bir şey bulursanız, c ++ versiyonunu yazmaya devam edebilirsiniz. ve bunun yardımcı olup olmadığını görmek (C ++, derleme zamanında daha iyi optimize etme eğilimindedir). Arayüz oluşturduğunuz API'lar da yazılırsa Objektif C kullanımı daha kolay olacaktır, artı OOP tarzının daha kolay veya daha esnek olduğunu görebilirsiniz.

Sonunda, güvenli, sağlam bir kod yazabildiğinizi ve diğer dilden özel ilgi gerektiren bir alan bulursanız, bununla birlikte takas edebilirsiniz. X-Code, aynı projede hem derlemenizi sağlar.


7
2017-11-25 13:44



Çok iyi cevap. Bunun için teşekkürler. - Bunkai.Satori
İyi akıl yürütme. - overboming


Bir iPhone 3G'de neredeyse 2 yıl önce yaptığım birkaç testim var, o günlerde belge veya sert sayı yoktu. Hala geçerli olduklarından emin değil, ancak kaynak kodun gönderildiği ve eklendiğinden emin değilsiniz.

Bu çok kapsamlı bir test değil, esas olarak çok sayıda nesnenin yinelenmesi için NSArray vs C Array ile ilgileniyordum.

http://memo.tv/nsarray_vs_c_array_performance_comparison

http://memo.tv/nsarray_vs_c_array_performance_comparison_part_ii_makeobjectsperformselector

C Array'in yüksek iterasyonlarda çok daha hızlı olduğunu görebilirsiniz. O zamandan beri darboğazın muhtemelen NSArray'ın yinelemesi değil, mesajın gönderilmesi olduğunu fark ettim. MethodForSelector'ı denemek ve farkın ne kadar büyük olacağını görmek için doğrudan yöntemlere çağırmak istedim ama hiçbir zaman bu işe yaramadı. Mike Ash'in kriterlerine göre, 5 kat daha hızlı.


3
2018-02-06 18:41



Eh, bir C dizisine erişme kelimenin tam anlamıyla işaretçiye ofset ekleyerek ve sonuçta ortaya çıkan işaretçiyi iptal etmekten başka bir şey değildir. Bundan daha hızlı elde etmek zor. - Arafangion
@memo Bağlantılar öldü, ama işte bölüm, ve bölüm ii - bobobobo
Bağlantıları görebiliyorsan, bu büyük bir cevaptır. Özetlemek gerekirse C dizisini bulur en az 100x daha hızlı göre NSArray - bobobobo


Objective C için zor bir veri yok ama C ++ için iyi bir yerim var.

C ++, C ++ 'nın ilk yıllarındaki yansımasında Bjarne Stroustroup'a göre Sınıflar ile C olarak başladı (http://www2.research.att.com/~bs/hopl2.pdf), böylece C ++ (Objective C gibi) nesne yönelimi için kendi sınırlarına C basmak olarak düşünülebilir.

Bu limitler nelerdir? 1994-1997 döneminde, pek çok araştırmacı, nesne yöneliminin, dinamik bağlanma, ör. C ++ işlevleri sanal olarak işaretlendiğinde ve bu işlevleri geçersiz kılan alt sınıflar / olmayabilir. (Java ve C # 'da, tüm fonksiyonlar cetvellerin sanal olarak sanal olmasını bekler ve bu konuda yapabileceğiniz pek bir şey yoktur.) IBM Research Tokyo'daki araştırmacılardan "Bir Java Tam Zamanlı Derleyici İçin Devrimualizasyon Teknikleri Üzerine Bir Çalışma" Urz Hölzle ve Gerald Aigner'den biri de dahil olmak üzere, bununla başa çıkmak için kullanılan teknikleri karşılaştırıyorlar. Urz Hölzle, Karel Driesen ile ayrı bir makalede, C ++ programlarındaki zamanın ortalama% 5.7'sinin (ve ~% 50'ye kadar) sanal fonksiyonları (örn. Vtables + thunks) aramada harcanmış olduğunu göstermişti. Daha sonra, bu sorunları OO'da çözmek için Java HotSpot VM'ye son veren bazı Smalltalk researachers ile çalıştı. Bu özelliklerin bazıları C ++ (örneğin 'korumalı' ve Özel Durum işleme) için desteklenmektedir.

Bahsettiğim gibi, C ++, Objective C'nin ördek tipli olduğu yerlerde statik olarak yazılmıştır. Uygulamadaki performans farkı (ancak kod satırları değil) muhtemelen bu farklılığın bir sonucudur.


3
2018-01-08 16:37



Amaç-C, ördek tiplemeyi kullanmaz. Nesnelerin ya belirli bir türü var ya da tip id. Ördek yazarak çalışma zamanı, içeriğe bağlı olarak bir tip atar. Objective-C çalışma zamanı türleri tayin etmez. - TechZen
C # (.net) 'de tüm işlevler sanal değildir. Bu java ve .net arasındaki farklardan biridir. Sanal veya soyut anahtar kelimelerle sanallaştırmak istediğiniz her yöntemi açıkça işaretlemeniz gerekir. - Rui Craveiro
@TechZen: Bu, en azından Ruby topluluğunda "ördek yazarak" terimini anlamayla çelişir. Ruby, evrensel olarak ördek cinsi olarak görülür, ancak her bir nesne aslında belirli bir türe sahiptir (sınıf; ayrıca daha da uzmanlaşmış olan tekil yöntemlere de sahip olabilir). Ördek yazmanın, belirli bir türün varsayıldığı bir nesneye mesaj gönderebilmenizin yolu olduğu anlaşılmaktadır. davranışyanıt olarak ancak belirli bir türü varsaymıyor. - echristopherson


Bu çalışma CPU yoğun bir oyundaki performansı gerçekten almayı söylüyor. C'yi kullanmanız gerekiyor. Bağlantılı makale, çalıştırabileceğiniz bir XCode projesiyle tamamlandı.

İnanıyorum alt çizgi is: iPhone'un işlevleriyle etkileşimde bulunmanız gereken Objective-C'yi kullanın (sonuçta, her yerde trambolin koymak herkes için iyi olamaz), ancak döngüler söz konusu olduğunda, vektör nesnesi sınıfları veya yoğun dizi erişimi gibi şeyler, iyi performans elde etmek için C ++ STL veya C dizileriyle yapışır.

Yani görmek çok aptalca olurdu. position = [[Vector3 alloc] init] ;. Bir pozisyon vektörü gibi temel nesnelerde referans sayımları kullanırsanız, sadece bir performans isabeti istersiniz.


1
2017-09-07 19:14





Evet. c ++ performans / expresiveness / resource tradeoff içinde yüce hükümdarlık.

“Zorlu veri arıyorum, evangelizm değil”. google senin en iyi arkadaşın.

  1. obj-c nsstring, performans için Apple enginneers tarafından c ++ ile değiştirildi. Kaynak kısıtlı cihazlarda, sadece c ++ bir MAINSTREAM oop dili olarak keser. NSString stringWithFormat yavaş

  2. obj-c oop soyutlama, performans için prosedür tabanlı c-yapılarına dönüştürülür, aksi takdirde bir MAGNITUDE düzeni java'dan daha yavaştır! Yazar ayrıca mesaj önbelleklemenin de farkındadır - yine de yok. Bu nedenle, çok sayıda küçük oyuncu / düşman nesnesinin modellenmesi c ++ veya başka bir deyişle, objeleri ile objenin etrafındaki basit bir OOP sarmalayıcısına sahip çok sayıda Procedural yapı ile yapılır. Procedural + Nesneye Dayalı Programlama = obj-c'yi eşitleyen bir paradigma olabilir. http://ejourneyman.wordpress.com/2008/04/23/writing-a-ray-tracer-for-cocoa-objective-c/


-1
2018-06-09 13:20



Bana evangelizm gibi geliyor - Chris Devereux