Ceday Mesaj tarihi: Eylül 11, 2005 Paylaş Mesaj tarihi: Eylül 11, 2005 hayır o düzgün bir çözüm degil. o zaman projeyi manage edememeye baslarsın. ortalıkla yüzlerce gereksiz, aslında olmaması gereken fonksiyonlar olur ve cok fazla karışıklıga yol açar. performans kaybına gelince, rahan deminki konuya geliyoruz işte. birebir performanslarını karşılastırırsan elbetteki hashtable yerine düzgün parametre alan bir fonksiyon daha hızlı çalışır. ama ne kadar hızlı?? 10 tane parametre alan bi fonksiyonda hashtabledan 10 parametre cekip "cast" ediceksin. Daha sonra bunları normal parametrelermiş gibi kullanacaksın. Ama bu aradaki fark önemsenmiyecek kadar az oldugu için cok birşey değiştirmez. Programlardaki optimize etme olayları bunlar üzerinde yapılmaz zaten. "Hot Spot" denen kavramlar vardır. Bunlar üzerine yogunlasılır. DB kullanan programlarda (en fazla geçen zaman genelde DB accesstir) DB Cache yazar kullanırsın, en fazla access edilen şeyleri memoryde (cok büyükse dosyada) cache edip istek gelince gönderirsin. DB optimizede senin o sekilde yapacagın değişiklik hiçbir görünür değişiklige yol açmaz. Ama cache ciddi bir biçimde performans arttırır. Kaldı ki, büyük projelerde kodların ve veritabanlarının anlaşılabilirligi cok önemlidir. Herkesin tasarlayacagı tablolarda kendince değişik şeyler yapmaya kalktıgını düşünürsen tepe taklak gider walla o proje. Neyse konu cok uzadı ve saptı :) Link to comment Sosyal ağlarda paylaş Daha fazla paylaşım seçeneği…
Rahan Mesaj tarihi: Eylül 11, 2005 Paylaş Mesaj tarihi: Eylül 11, 2005 fonksyonun aynı kod içerisinde yüzlerce farklı versyona uyum sağlamaya çalışmasından çok daha iyi bir çözüm olur ayrı ayrı duran overloaded fonksyonlar. en azından son versyon fonksyon tertemiz kalır. gerektiğinde cart diye silersin. hadi 300 tane programcının beraber çalıştığı yerde ağır bi framework kullanılmasını anlarım da.. tamsayı olarak tutulan ip adresini okuduğunda anlayamayacak kadar acemi adamı onların arasında pek kabul edemiyorum.. neyse son olarak ben lafımı atayım; önerdiğim teknik stringden daha hızlı ve daha az yer kaplar, projeye veya şirkete uygun olup olmaması bunu değiştirmez..[signature][hline]pppppt.. kediler çorba içmezki! Link to comment Sosyal ağlarda paylaş Daha fazla paylaşım seçeneği…
Ceday Mesaj tarihi: Eylül 11, 2005 Paylaş Mesaj tarihi: Eylül 11, 2005 said: Rahan, 11 Eylül 2005 18:17 tarihinde demiş ki: neyse son olarak ben lafımı atayım; önerdiğim teknik stringden daha hızlı ve daha az yer kaplar, projeye veya şirkete uygun olup olmaması bunu değiştirmez.. ben zaten aksini iddia etmedim ki. aradaki ms bazındaki degerler için db yi bu sekilde değiştirmenin mantıksız oldugunu söyledim sadece. kaldı ki 212.212.212.212 gibi bir ip yi db ye yazınca kim bilir ne hale gelecek..adam görünce tabi anlamaz. Link to comment Sosyal ağlarda paylaş Daha fazla paylaşım seçeneği…
Rahan Mesaj tarihi: Eylül 11, 2005 Paylaş Mesaj tarihi: Eylül 11, 2005 öyle okumak değil ya, kodun içinde ip nin nasıl tutulduğunu anlatan commentleri okuyunca anlamamasından bahsediyorum.[signature][hline]pppppt.. kediler çorba içmezki! Link to comment Sosyal ağlarda paylaş Daha fazla paylaşım seçeneği…
Öne çıkan mesajlar