PerryTS/perry

Problem crates/perry-codegen/src/codegen/string_pool.rs looks up method and property names with strings.iter().find(|e| e.value == …) in four places (~L1085, ~L1143, ~L1421, ~L1524), once per class method or property registration. That's O(pool size × members). On a large bundle (~190k pool entries, tens of thousands of members) it's a pure compile-time waste. Fix Use (or expose) the pool's existing intern index (a HashMap<String, idx> or similar that interning already maintains) for these lookups. The emitted IR must not change. Verify cargo test --release -p perry-codegen passes, and the emitted IR is byte-identical before and after on the gap corpus (e.g. --trace llvm diff on a sample of test-files). A compile-time probe: generate a program with ~500 classes × 50 methods, and time perry compile before and after (report). Rules for the PR (repo conventions) Code + tests + a changelog.d/<PR>-<slug>.md fragment. No version bump (don't touch [workspace.package].version, the CLAUD

Problem parent_dense_store (crates/perry-runtime/src/object/class_image.rs ~L343–346) initialises the per-image dense parent table with (0..PARENT_DENSE_CAP).map(|_| AtomicU32::new(0)).collect(), i.e. 65,536 AtomicU32. That is 256 KiB written element-by-element (every page dirtied) the first time any class has a parent. The same pattern is used for the anon fast-slot table (~L369). Separately, parent_static.rs (~L25–45) publishes each in-window edge to the dense table and inserts it into the CLASS_REGISTRY hash map under a write lock, so every in-window edge is stored twice. Fix Allocate the table zeroed (Box::<[AtomicU32]>::new_zeroed_slice(N) + assume_init, or allocate [u32] zeroed and transmute; 0 already means "no parent"), so untouched pages stay clean. Consider sizing to the program's max class id if cheaply known. For class ids inside the dense window, skip the CLASS_REGISTRY insert, and make every reader consult the dense table first for in-window ids. Audit all CLASS_REGI

Summary Add an opt-in WinUI 3 / Fluent rendering backend for Windows, selectable via --target windows-winui, alongside the existing Win32/GDI backend (crates/perry-ui-windows). Motivation from discussion #3486: the current Win32/GDI output looks dated (boxy, flat, no animation, Win7-era controls). WinUI 3 brings Fluent Design — rounded corners, Mica/Acrylic materials, smooth animations, modern typography, crisp auto-DPI — and is the closest Windows analog to our iOS/Android look-and-feel. Scope / decisions Opt-in, not the default. WinUI 3 requires the WinAppSDK runtime + an MSIX/bootstrapper packaging story, which conflicts with Perry's single-native-.exe model. Keep Win32 as the default target; expose WinUI via --target windows-winui. Mirrors how we ship multiple Apple targets. No new "UI framework" dependency confusion: microsoft/windows-rs (already a dep, windows = "0.58") is the WinRT projection crate, not a UI lib. WinUI from Rust = driving WinAppSDK + XAML through the WinRT

The problem Some developers prefer to use signals for UI updates rather than React with its heavy-handed virtual DOM / diff algorithm. SolidJS is the fastest renderer out there -- a nice fit with perry/ui on mobile devices where speed and small memory footprint are desired. Proposed solution The SolidJS package is not tied to a web DOM renderer and is used by other non-web frameworks to generate a native UI. To implement this, you can use SolidJS with a universal renderer and only have to implement the following: createElement(string) { return document.createElement(string); }, createTextNode(value) { return document.createTextNode(value); }, replaceText(textNode, value) { textNode.data = value; }, setProperty(node, name, value) { if (name === "style") Object.assign(node.style, value); else if (name.startsWith("on")) node[name.toLowerCase()] = value; else if (PROPERTIES.has(name)) node[name] = value; else node.setAttribute(name, value); }, insertNode(parent, node, anchor)