ENABLE_OPTIMIZATION_ITEMPROTO_O1

Sn0Xx · 20 Nis 2026

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.

---------------------------------------------------------------------------------