ENABLE_OPTIMIZATION_ITEMPROTO_O1
- Aşağıdaki direktif eklendi:
- Server/common/CommonDefines.h
- #define ENABLE_OPTIMIZATION_ITEMPROTO_O1
- Server/common/CommonDefines.h
- Game Core:
- Server/game/src/item_manager.h
- m_map_itemProtoByVnum (TR1_NS::unordered_map<DWORD, TItemTable*>)
- m_map_itemProtoByRangeCache (TR1_NS::unordered_map<DWORD, TItemTable*>)
- Server/game/src/item_manager.cpp
- Initialize() sırasında O(1) map yapısı oluşturuldu,
- reload sırasında yapılar temizleniyor (m_vec_item_vnum_range_info, m_map_vid, O(1) map’ler),
- GetTable() ilgili direktif altında O(1) yoluna geçirildi + range/cache fallback korundu.
- Server/game/src/item_manager.h
- DB Core:
- Server/db/src/ClientManager.h
- m_map_itemTableByVnum ilgili direktif altında boost::unordered_map olarak değiştirildi.
- Server/db/src/ClientManager.h
Önceden sunucu item verisini daha yavaş bir yöntemle arıyordu.
Şimdi ise vnum üzerinden daha hızlı bir arama sistemi eklendi.
Tam olarak ne yapıldı?
unordered_map tipinde map’ler eklendi. Bu sayede item proto çok daha hızlı bulunabiliyor.
Şunun yerine:
- ara yapılarda arama yapmak,
- ya da daha yavaş bir arama çalıştırmak,
sunucu artık şunları yapabiliyor:
- doğrudan vnum değerini kontrol etmek,
- ve ilgili TItemTable verisini almak.
Bu neden daha hızlı?
Çünkü önceden lookup yaklaşık olarak şöyleydi:
- O(log n),
ya da kullanılan yola göre daha yavaş,
şimdi ise:
- exact lookup’lar için ortalama O(1).
Yani:
- item ile ilgili işlem sayısı ne kadar fazlaysa,
- bu değişikliğin anlamı ve katkısı o kadar büyük olur.
Bu nerelerde önem kazanıyor?
Özellikle hot path’lerde, yani sunucunun itemlerle çok sık çalıştığı yerlerde:
- char_item.cpp
- shop_manager.cpp
- item.cpp
- cube.cpp
- mağaza sistemleri,
- questler,
- tombala,
- item oluşturma işlemleri
Range kullanan itemlerde durum ne?
dwVnumRange için eski mantık korunmuştur.
Yani:
- exact vnum doğrudan map üzerinden bulunur,
- item range üzerinden çalışıyorsa yine fallback ve cache ile işlenmeye devam eder.
Proto reload durumunda ne oluyor?
Reload sırasında:
- eski map’ler temizleniyor,
- cache temizleniyor,
- her şey baştan yeniden oluşturuluyor.
Bu önemlidir çünkü map’ler m_vec_prototype içindeki verilere işaretçi tutuyor.
Eğer yeniden oluşturulmazlarsa eski veya geçersiz kayıtlar kalabilirdi.
Pointer güvenliği nasıl sağlandı?
Geliştirici bunu şu şekilde ele aldı:
- exact/range map’ler Initialize() sırasında yeniden oluşturuluyor,
- eski yardımcı yapılar da temizleniyor,
- mevcut itemler yine SetProto(GetTable(...)) ile proto almaya devam ediyor.
Yani amaç, reload sonrasında eski pointer’ların kalmamasını sağlamaktır.
Gerçek etkisi nedir?
Tüm core’un sihirli şekilde %50 daha hızlı olmasını beklemeyin.
Daha gerçekçi olarak:
- tekil proto lookup artık daha ucuz,
- tüm core birkaç % CPU kazanabilir,
- en büyük etki, item işlemlerinin yoğun olduğu yerlerde görülür.
---------------------------------------------------------------------------------
