iced-rs/iced

Perform benchmarks

Offen

#7 geöffnet am 05.09.2019

Auf GitHub ansehenContributor Guide
 (5 Kommentare) (0 Reaktionen) (0 zugewiesene Personen)Rust (1.572 Forks)batch import
help wantedimprovementperformance

Repository-Metriken

Stars
 (30.491 Sterne)
PR-Merge-Metriken
 (Durchschn. Merge 24T 11h) (11 gemergte PRs in 30 T)

Beschreibung

As mentioned in #4, in order to avoid performance regressions, it would be great to run some benchmarks on the different parts of the API.

The most expensive operation is clearly UserInterface::build. This will be the main focus for many of the optimizations we will implement in the future. We should benchmark this first.

UserInterface::update and UserInterface::draw will also get slower the more widgets and events a user interface has to handle. It would be great to have some numbers!

Contributor Guide

Research-Richtung
Dieses Issue fordert die Hinzufügung von Benchmarks für die Methoden build, update und draw der UserInterface Struktur. Der aufwändigste Vorgang ist UserInterface::build, also beginnen Sie damit. Sehen Sie sich den vorhandenen Codebase an, um zu verstehen, wie UserInterface implementiert ist (wahrscheinlich in src/user interface.rs oder ähnlich). Verwenden Sie die criterion Crate für das Benchmarking. Prüfen Sie, ob es bereits vorhandene Tests oder Benchmarks im Repository gibt (z. B. im Verzeichnis benches/). Überprüfen Sie auch die Kommentare zum Issue auf frühere Diskussionen zum Ansatz. Konzentrieren Sie sich darauf, ein Benchmark Harness zu erstellen, das die Zeit dieser Methoden mit verschiedenen Widget Anzahlen misst.
Tech Stack
rust
Domain
frontend
Issue Type
Performance
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
3
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
1-2 Tage
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Aktiv
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Klar
Voraussetzungen
RustGit
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
65