Öncelikle herkese günaydın, Bizim bir dersimizde java ile mobil oyun programlıyoruz. Dikkatimi çeken konu oyunu tek sınıf üzerinde kodluyoruz. Neredeyse hiç OOP kullanmıyoruz. Bunu öğretmenimize danıştığımda sadece performans odaklı olduğunu söyledi. Containerları da kullanmıyoruz. Direk diziler ile işimizi hallediyoruz. Bunun sebebi galiba generic yapılar performansı etkiliyor. Emin değilim. Sizlere soruyorum :) Benim kendi düşüncem böyle java ile kodlamak yerine daha hızlı diller olan D, C/C++ ile kodlansa daha mantıklı olmaz mı? Sonuçta direk javanın kendisi de bu dillere göre performans kaybı. Sizler performansın önemli olduğu projelerinizde nasıl yol haritası çiziyorsunuz? Ve OOP performansı cidden bu kadar etkiliyor mu?

Herkese iyi çalışmalar.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

OOP 'nin performansa kötü bir etkisi olduğunu konusunda bir bilgim yok.

İyi performans için en önemli şeylerden biri okunabilir kod olduğunu düşünüyorum. Eğer OOP yöntemleri yazılan kodu daha okunabilir hale getiriyorsa tam tersi şekilde performansıda iyileştirecektir.

Şimdi biraz günahını alacağım biraz dersi veren öğretmeninin , kötü adam olacağım affola; sektörde kendini geliştirmeyen akademisyenler, tekniksiyenler, mühendislerin klasik sebep göstermelerinden biridir bu performans argümanı. Halbuki sebep benim açımdan kendilerini geliştirmemeleridir.

Sana tavsiyem ölçüm(benchmark) göstermeden performans konusunda fikir belirten insanlara genelde şüphe ile yaklaşman olacaktır.

2000'li yılların başında OOP 'nin herşeyi çözdüğü ön yargısı vardı buda yanlış bence. Ama çekiç ile nasıl bir kabloyu kesemezsek her araçı doğru problem için kullanmamız gerektiğini düşünüyorum.

Ben openGL 'den ekmeğini kazanan biri olarak OOP'yı "grafik pipeline' 'ın en derinlerinde bile kullanıyorum. Gerçek performans sorunları bambaşka şeylerden kaynaklanıyor.

Sana tavsiyem oyun geliştirme için şu kanalın bütün videolarını seyretmen olacaktır: https://www.youtube.com/watch?v=VS8wlS9hF8E
Oda java ile yazıyor ve OOP'yi çok güzel harmanlıyor.

Erdemdem

Bu arada Hasan bana mail atarmısın ben seninkini bulamadım eğer oyun geliştirme ile ilgileniyorsan benim çalıştığım firmada staj olursa filan ilgilenirmisin. Mailim kerdemdemir@gmail.com .

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Udemy hocalarından biri olan olan Engin Demiroğ (IG Hesabı (https://www.instagram.com/engindemirog/)), son zamanlardan InstaGram'da çok elzem konularda küçük dersler veriyor. Örneğin şu: https://www.instagram.com/p/Bre-Jd-hZW8/

Belki onu takip ederek bu konuda güncel uygulamalara ulaşabilirsin.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Bir şeyler ekliyesim geldi, önceki cevabımı değiştirmek yerine yeni bir cevap yazmaya karar verdim.

OOP'nin can damarı polymorhism'de vTable'lar kullanılır. Burda bir tablo arama gerçekleştirilir ve bir masraf vardır. Ayrıca objelerimiz artık POD değildir extra 4byte yer kaplarlar bu gizli gösterici için. Fakat bunların hepsi 100000 vertex'den oluşan bir objeyi CPU'dan GPU'ya yollarken ki masrafın yanında devede tüy kalırlar. 100000 vertex en basit oyunlarda ve simulasyonlarda bile çok sıradan artık milyonlarca vertexler havalarda uçuşuyor.

En önemli olan oyun geliştirmede veya simulasyonda yani openGL tabanlı uygulamalarda bence "computer graphics" konusunu anlamak algoritmaları bilmek ve sahip olduğumuz donanımı bilerek donanımın avantajlarını tamamen kullanmak.

Tabi 10mb bir objeyi referans olarak geçmeliyiz kopyalamamalıyız ama kodu daha okunabilir ve yönetilebilir yaptığı sürece OOP 'nin dynamic cast veya fonksiyon eşleşmesi masraflarını düşünmemize gerek yok bence

Erdemdem

Ali Abiye cevap gibi olmuş ben yazmaya başladığımda başka mesaj yoktu. Mesajı aynı anda yazıyormuşuz Ali Abi önce bitirmiş. Düğmemi ilikleyip saygımı belirtiyorum :) . Şimdi okuyorum Ali Abi'ninkini eğer bir ikilem var ise her zaman Ali Abi'nin söylediğini tercih ediniz :).

Hüseyin ben senin adını yaklaşık 2 aydır yanlış söylüyormuşum bunuda öğrenmiş oldum kusuruma bakma lütfen.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Öncelikle uzun uzun açıklamışsınız hepinize teşekkür ederim. Bu forum benim için çok değerli. Sizlerin burada paylaştıklarınız bana çok yardımcı oluyor.

Alıntı (kerdemdemir):

Hiç problem değil :)

Alıntı (kerdemdemir):

Düşünceleriniz beni çok mutlu etti, hem de çok heyecanlandırdı. Ben daha önce de gönüllü çalışmak için staj yerlerine başvurdum fakat ne yazık ki ya zorunlu staj ya da son sınıf olmamı istiyorlardı. Şimdi bu yazıyı görünce çok mutlu oldum. Size hemen mail atıyorum.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

• Hasan değil, Hüseyin. ;)

• OOP'yi gerektiren veya ondan yararlanan programlar sanıldığından azdır. İlgisiz olarak, OOP'nin bugün yaygın olan gerçekleştirmeleri (C++, D, Java, vs.) yanlış denebilecek kadar sorunludur. (Bakınız: "expression problem", "anemic design model", "open methods", vs.)

• Evet, OOP'nin yaygın gerçekleştirmesi olan vtbl pointer, performans açısından zararlıdır çünkü asıl türleri farklı olan bir dizi elemanın işlemlerini işletirken her elemanın işlev göstergesini bulmak bellekte zıplamayı gerektirir: nesnenin vtblptr'ını oku, vtblptr'ın gösterdiği yerdeki tablo göstergesine işletilecek olan işlevin offset'ini ekle. Oradan okuyacağın işlev gösterge değerinin gösterdiği yerdeki işlevi işlet.

Bunu kod içindeki basit bir 'switch' ile karşılaştırınca switch'li yöntemin bellekte farklı yerlere zıplamayabileceğini görürüz. Bellekte farklı yerlere erişmek işlemcinin ara belleğinin etkin kullanımına ters olduğundan vtblptr'lı OOP bu konuda geri kalır.

• Performans konusunda herkesin bilmesi gereken, ne benim, ne de başkasının söylediğine güvenmektir: ölçmeden bilinemez.

• Dizi, programcılıkta en çok kullanılan veri yapısıdır. Bazı durumlarda da en hızlısıdır. Örneğin, elemanların baştan bir kere girildiği ve bir daha eleman çıkarılmadığı durumda, diziyi önceden sıralamak ve ikili arama vs. gibi işlemlerle kullanmak en hızlısıdır. Gösterge vs. için bellek harcanmamıştır ve herkes bellekte yan yana durduğundan işlemcinin ara belleği için de çok uygundur. (İşlemcilerin ara bellekleri zaten dizi üzerinde ilerlemeyi hızlandırmak için tasarlanmıştır.)

• Sanırım "generic" terimi ile ifade edilen kavram Java gibi dillerde ve D gibi dillerde farklı gerçekleştirilmiştir. Yanılmıyorsam, Java'da farklı türler için tek gerçekleştirme kullanılır ama olayın için göstergeler vardır. D gibi dillerde ise şablonlar (template) kullanıldığından her tür için farklı kod üretilir. Ben şablonların genelde daha hızlı olduğunu sanıyorum ama program boyutunu büyüttüklerinden yine işlemci ara bellekleri ile ilgili olarak yavaşlık da getirebilir.

• D gibi dillerin Java'dan daha hızlı oldukları her zaman için doğru değil. Örneğin, D'de JIT yok. Hangisinin daha yararlı olduğunu bakmadan bilemeyiz. Eğer Java'nın çöp toplayıcısı programın duraksamasına neden oluyorsa, aynısı D de var.

• Ben performansın önemli olduğu bir projede D kullandım (diğer seçenekler Python ve C++ idi). Ama bunu deneme yapıp sonuçlarına bakarak değil, D ile programlamak istediğim için yaptım. Utanmadan söylüyorum: Ben bir insanım ve insanları ilgilendiren psikolojik etkiler altındayım. :) (Bir başka deyişle: robot değilim.) Eğer D yetersiz olsaydı başka dil kullanırdım. D ile yazmak beni mutlu etti ve çok verimli çalışmamı sağladı. (Bu projeyi DConf konuşması olarak sundum; kabul edilirse deneyimimi anlatacağım.) Dilleri karşılaştırım "şunu dili şu yüzden seviyorum" diyen kişilerin de aslında o dili "istedikleri" için öyle düşündüklerini düşünüyorum. "Evet, falanca ve filanca diller de çok iyi diller ama ben istediğim için benim seçtiğim dili kullanıyorum" diyebilmek gerek. :)

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (acehreli:1552756492):

Olumsuz bir cümle mi; doğru mu anlamışım?

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Bu konuda seneler önce başka bir arkadaşla da sorun yaşamıştım. Anlaşılan bu kullanım Türkçe'de değişiyor. Benim bildiğim, benimki doğru çünkü olumsuz anlamı vermek için "ne ona ne buna güven" denir. "güvenme" olacaksa "ona da buna da güvenme" olur. Ama evet, yine de anlaşıyoruz. :)

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Hocam bu durum, İngilizce'nin etkisi. Konuyu en iyi açıklayan kaynak şurada:

http://turkoloji.cu.edu.tr/YENI%20TURK%20DILI/nadir_ilhan_turkcede_olumsuzluk.pdf

Bu arada yakın zamanda Telegram'daki bir odada (Engin Demiroğ'un kuruculuğunda) OOP'da interface konusu işlendi:
Alıntı ("Barbaros YURTTAGÜL"):

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

"Bu durum" derken benim "ma" olumsuzluk ekini eksik bırakmamı mı kastediyorsun yoksa "ma" eki olmadığında bir eksiklik olduğunu düşünmemizi mi? :)

Belge için teşekkürler. Benim "ne .. ne de" kullanımım orada Türkçe'deki olumsuzluk anlamları arasında hiçbir yabancılık belirtilmeden geçiyor:

"Asıl fiiller olumsuzluk anlamı kazandırmak için kullanılan –mA- eki, ek-fiillerde kullanılmaz."

"Ne Ali ne de Ahmet geldi. = Hem Ali hem de Ahmet gelmedi."

"Türkçenin Söz Dizimi adlı eserinde Karahan da “ne ... ne...” edatının kelimeleri, kelime gruplarını veya cümleleri bağlayarak cümleleri olumsuz yaptığını, ancak bu tür cümlelerde yüklemin olumlu anlam taşıdığını örnekleriyle açıklamıştır. (Karahan 2004: 105)"

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]