iced-rs/iced

Perform benchmarks

Ouverte

#7 ouverte le 5 sept. 2019

Voir sur GitHubGuide contributeur
 (5 commentaires) (0 réaction) (0 personne assignée)Rust (1 572 forks)batch import
help wantedimprovementperformance

Métriques du dépôt

Stars
 (30 491 étoiles)
Métriques de merge PR
 (Merge moyen 24j 11h) (11 PRs mergées en 30 j)

Description

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!

Guide contributeur

Direction de recherche
Cette demande propose d'ajouter des benchmarks pour les méthodes build, update et draw de la structure UserInterface. L'opération la plus coûteuse est UserInterface::build, commencez donc par celle ci. Examinez la base de code existante pour comprendre comment UserInterface est implémenté (probablement dans src/user interface.rs ou similaire). Utilisez la crate criterion pour le benchmarking. Vérifiez s'il existe des tests ou benchmarks existants dans le dépôt (par exemple, le répertoire benches/). Consultez également les commentaires sur la demande pour toute discussion antérieure sur l'approche. Concentrez vous sur la création d'un harness de benchmark qui mesure le temps de ces méthodes avec différents nombres de widgets.
Stack technique
rust
Domaine
frontend
Type d'issue
Performance
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
3
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-2 jours
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
RustGit
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
65