ENABLE_OPTIMIZATION_ITEMPROTO_O1

ENABLE_OPTIMIZATION_ITEMPROTO_O1​

• Aşağıdaki direktif eklendi:
  • Server/common/CommonDefines.h
    • #define ENABLE_OPTIMIZATION_ITEMPROTO_O1
• 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.
• DB Core:
  • Server/db/src/ClientManager.h
    • m_map_itemTableByVnum ilgili direktif altında boost::unordered_map olarak değiştirildi.

Ö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.
  
  ---------------------------------------------------------------------------------
  
  
  

Paylaşım için teşekkürler.

teşekkürler

Paylaşım için teşekkürler