chore: pin plugin-warehouse v0.1.4 — depo sahnesindeki donma düzeltmeleri

[ovurrsl]

Yalnız pin: 9e1b525 → fd22b04 (plugin-warehouse v0.1.4). Editör kaynağında değişiklik yok — apps/editor/package.json 2 satır + bun.lock 4 satır.

Neden

Bir depo projesini açmak yetiyordu: kullanıcı hiçbir şeye dokunmadan editör kasıyor, kat çoğaltınca tamamen kilitleniyordu — kamera bile oynamıyordu.

Kullanıcının kendi makinesinden gelen ölçüm bunun yükleme takılması değil, kalıcı bir kare maliyeti olduğunu gösterdi: 41,3 saniyede toplam 22 kare (0,5 fps), p50 kare süresi 2098 ms, ana iş parçacığı %98,9 bloke. Kritik olan, kat çoğaltmadan önce de sahnenin boş boş dururken kare başına ~1,15 saniye harcıyor olmasıydı.

İki noktadan doğrusal model: kare ≈ 260 ms sabit + 330 µs × raf sayısı. Raf sayısı ikiye katlandığında raf başına maliyet değişmiyor — yani her karede, sonsuza dek, raf başına sabit bir iş dönüyor. 330 µs raf başına, bir WebGL2 çizim çağrısının (tek haneli µs) iki-üç kat büyüklük üstünde, ve eklenti sahnenin tamamını ~95 çizim çağrısında çiziyor: maliyet GPU'da değil, CPU'da JavaScript'te.

v0.1.3 + v0.1.4'te ne var

Kirli bayrağı tüketimi (v0.1.3). FloorElevationSystem kirli bayrağını yalnız def.geometry ya da def.system bildirmeyen kind'lar için düşürüyor:

if (!(def.geometry || def.system) && dirtyNodes.has(id)) clearDirty(id)

Bildiren kind'lar bayrağı kendileri tüketmek zorunda — host'un dokuz yerleşik sistemi bunu yapıyor. Eklenti def.system bildirip hiçbir yerde clearDirty çağırmıyordu. Tetikleyici sahne yüklemesinin kendisi: her slab markNodesOverlappingSlab taramasını koşuyor ve ayak izine değen her capabilities.floorPlaced düğümünü kirletiyor — bir depoda rafların tamamı. Bayrak düşmediği için küme bir daha boşalmıyor, ve dirtyNodes.size === 0 on iki host sisteminin ortak erken çıkışı. Yukarıdaki ölçümün gösterdiği kalıcı kare maliyetinin şekli tam olarak bu.

Şekil anahtarı memoizasyonu (v0.1.4). rackGeometryKey mount başına dört, sonraki her render'da iki kez çağrılıyor ve her çağrı seviye yapısını sıfırdan türetiyordu — o da seviye sayısında kareselleşen bir iş. Bildirilen dosyada 2.708 raf yalnız dört farklı şekle çözülüyor. Çağrı başına 12,7 µs → 0,31 µs (41×).

Kademeli mount, tüm kind'lara (v0.1.3 → v0.1.4). Kapı v0.1.3'te yalnız warehouse:pallet-rack'teydi; kolektif çizen on üç kind'ın on ikisi hâlâ tek React commit'inde mount oluyordu. Sözleşme host'un duvar yolundakiyle aynı (wall-system.tsx: "Large imports enter the progressive path so initial load can't lock the tab"), bütçe de aynı 8 ms — ve kind'lar arasında paylaşımlı. Dışa aktarımda kuyruk senkron boşaltılıyor, yani aktarılan dosyada eksik raf olmuyor.

Görünüşte hiçbir şey değişmiyor: aynı geometri, aynı malzemeler, aynı çizim çağrısı sayısı. Değişen tek şey, aynı işin kaç kez yapıldığı.

Bu PR neden üretime akmanın önkoşulu

deploy-bundle.yml yalnız main'e push'ta tetikleniyor (paths: apps/editor/**, packages/**, bun.lock), sonra bundle'ı derleyip ovurrsl/digitaltwin'e force-push ediyor. Eklenti uygulamanın içine derleniyor, yani bir eklenti sürümü siteye ancak yeniden derlemeyle ulaşıyor — workflow'un kendi yorumunun dediği gibi.

Pin bump'ı bir dalda durduğu sürece bu workflow hiç koşmuyor, bundle hiç tazelenmiyor. Düzeltmelerin canlıda görünmemesinin nedeni buydu; pinin kendisi zaten doğruydu.

Bu PR merge edilince pin commit'i apps/editor/package.json ve bun.lock'a dokunduğu için workflow kendiliğinden koşar.

bun.lock hakkında

Elle güncellendi. bun install bu ortamda pascalorg/plugin-trees tarball'ında 403 alıyor (erişim kapsamı dışında bir depo). Değişiklik mekanik ve doğrulandı:

• Aynı SHA üç yerde geçiyor (bildirim, github: çözümü, tarball anahtarı), üçü de değişti; eski SHA hiçbir dosyada kalmadı
• peerDependencies bloğunun v0.1.4'te birebir aynı olduğu karşılaştırmayla doğrulandı
• Diff önceki pin bump'larla aynı biçimde: package.json 2 satır + bun.lock 4 satır

Yine de gerçek bir runner'da bun install ile tazelenmesi iyi olur — depoda bunun için ayrı chore: regenerate bun.lock on a real runner commit'leri var.

Doğrulama

Eklenti tarafında bun test 1563 geçti, check-types temiz, lint bulgusu main ile birebir aynı. Her iki sürümün düzeltmeleri de koruma testleriyle geldi ve testlerin düzeltme geri alındığında başarısız olduğu ayrıca doğrulandı.

Etki kullanıcının makinesinde doğrulanacak — buradaki headless ortamda render bozuk (R3F çift kopyası, havuzlar kurulmuyor), o yüzden bu PR tarayıcıdan gelen kare süresi öne sürmüyor. Yukarıdaki 41× ve raf başına 330 µs doğrudan ölçüm.

Deploy sonrası test: projeyi aç (kasma var mı, raflar kademeli mi beliriyor), sonra zemin katı level duplicate yap. docs/olcum-kat-cogaltma.md betiği öncesi/sonrası tabloyu veriyor; "öncesi" tablosu yukarıda.

Açıkta kalanlar

Kat çoğaltmanın en pahalı iki adımı host'ta, eklentide değil: toplu düğüm oluşturmada O(K²) children yeniden kurulumu ve union'da olmayan kind'lar için boşa koşan doğrulama. 900 düğümde 64,8 ms → 4,6 ms ölçüldü. Yamalar eklenti deposunda docs/upstream-bulk-create.patch ve docs/upstream-autosave.patch olarak hazır, listesi docs/upstream-host-onerileri.md'de — bu PR'a dâhil değiller, editör kaynağına dokunmuyorum.

Bu makinede WebGPU yok (No available adapters → WebGL2 fallback). x86 PC'de olup iPhone 14 Pro'da olmaması bununla ilgili olabilir; yukarıdaki aritmetiğe göre baskın maliyet bu değil, ama açık bir iplik.

Not: sürüm tag'leri

Eklenti deposuna hiç tag push edilemedi — tag ref push'u 403 dönüyor (branch push aynı URL'le çalıştığı hâlde). release.yml tag push'unda tetiklendiği için GitHub release'i kesiliyor. Bu PR'ın içeriğini etkilemiyor: pin doğrudan SHA'ya bakıyor.