UPSTREAM PR #16757: webui: add HTML/JS preview support to MarkdownContent with sandboxed iframe

[DajanaV]

Mirrored from ggml-org/llama.cpp#16757

Extended MarkdownContent to flag previewable code languages,
add a preview button alongside copy controls, manage preview
dialog state, and share styling for the new button group

Introduced CodePreviewDialog.svelte, a sandboxed iframe modal
for rendering HTML/JS previews with consistent dialog controls

sandboxed-html-preview-AVC500kbps.mp4

[loci-agentic-ai]

Access the complete analysis in the LOCI Dashboard

Based on the performance analysis conducted for project 2621b8c0-b5ce-11f0-b333-453f42058aa1 comparing version cc0e41de-4e40-43e3-8ff3-249ad81c686c against base version 594f77ca-22bd-452c-8517-681d48c6e069, here are the key findings:

Performance Summary

Critical Function Changes

The analysis identified minimal performance degradations in non-critical functions:

• ~_Scanner destructor: +0.057% response time (+15 ns), +0.080% throughput (+15 ns)
• Quantization lambda __invoke: +0.116% bottleneck (+18 ns)

Power Consumption Analysis

• Total change: Negligible across all binaries (0.0% to +0.0003%)
• Affected binary: build.bin.libllama.so shows minimal increase (+0.0003%)
• Other binaries: No measurable changes in GGML libraries

KPI Impact Assessment

1. Tokens Per Second

Status: No impact detected

• Critical functions analyzed: No changes found in core inference functions
  • llama_decode(): Not identified in degradation analysis
  • llama_encode(): Not identified in degradation analysis
  • llama_tokenize(): Not identified in degradation analysis
• Reference impact: Given that 2ms slower llama_decode() reduces tokens/second by 7% on the reference system (ollama://smollm:135m, 12th Gen Intel i7-1255U, Ubuntu 24.04.3), the observed nanosecond-level changes in non-inference functions will not affect tokenization throughput

2. Power Consumption

Status: Minimal impact

• Affected binary: build.bin.libllama.so (+0.0003% increase)
• Unchanged binaries:
  • build.bin.libggml-base.so (0.0% change)
  • build.bin.libggml-cpu.so (0.0% change)
  • build.bin.libggml.so (0.0% change)
• Root cause: Micro-degradations in destructor and quantization helper functions

3. Quantization Efficiency

Status: Minimal impact

• Affected function: Quantization lambda __invoke in llama-quant.cpp
• Change: +18 ns bottleneck time (+0.116%)
• Impact scope: Internal quantization processing, not affecting llama_model_quantize() API performance

4. Memory Usage

Status: No impact detected

• Memory management functions: No changes identified in:
  • llama_memory_clear()
  • llama_memory_seq_rm()
  • llama_memory_seq_cp()
  • KV cache operations
• Assessment: Memory allocation patterns remain unchanged

5. Batch Processing

Status: No impact detected

• Batch processing functions: No changes identified in:
  • llama_batch_init()
  • llama_batch_get_one()
  • llama_batch_free()
  • llama_decode() with batches
• Assessment: Parallel token processing efficiency maintained

Root Cause Analysis

Assembly Code Analysis

The control flow graph comparison revealed identical assembly code between versions for the degraded ~_Scanner function, indicating the performance changes stem from:

• Build environment differences: Compiler version or optimization flag variations
• System library changes: Updated C++ standard library implementations
• Memory layout variations: Different ASLR or linking configurations affecting cache behavior

Code Change Correlation

The concurrent PR #23 contains only frontend Svelte/HTML modifications with no C++ code changes, confirming the performance degradations are build-environment related rather than code-driven.

Action Items

Build System Optimization

• Standardize build environment: Ensure consistent compiler versions and optimization flags across builds
• Link-time optimization: Consider enabling LTO to reduce PLT call overhead in destructor functions
• Static linking evaluation: Assess static linking benefits for reducing dynamic library call overhead

Performance Monitoring

• Baseline establishment: Implement consistent measurement protocols using hardware performance counters
• Build reproducibility: Establish controlled build environments to eliminate measurement noise
• Function-level tracking: Monitor core inference functions (llama_decode, llama_encode, llama_tokenize) for actual performance impacts

Code Quality Maintenance

• Template optimization: Review C++ standard library template instantiations for potential compiler-specific optimizations
• Memory layout analysis: Evaluate object member ordering for cache locality improvements in frequently destructed objects

The analysis confirms that core LLaMA.cpp inference performance remains unaffected, with observed degradations limited to auxiliary functions and likely attributable to build environment variations rather than functional regressions.