mre/hyperjson

Speed up boolean encoding/decoding

Ouverte

#68 ouverte le 21 sept. 2019

Voir sur GitHub
 (1 commentaire) (0 réaction) (0 personne assignée)Python (41 forks)github user discovery
enhancementgood first issuehacktoberfesthelp wanted

Métriques du dépôt

Stars
 (511 étoiles)
Métriques de merge PR
 (Aucune PR mergée en 30 j)

Description

From our benchmarks we can see that we are consistently slower than everyone else when serializing/deserializing boolean values. We should fix that.

orjson is using an unsafe block to create a reference to a boolean: https://github.com/ijl/orjson/blob/03d55e99a953ce93cedc05f03e4b63b0bcbbcc7a/src/decode.rs#L81-L96

This avoids additional allocations. For comparison, this is our code at the moment:

https://github.com/mre/hyperjson/blob/ded13b4100638aa32fe19dc477f5cfe3e704893c/src/lib.rs#L475-L480

I wonder if we could achieve comparable performance without using unsafe. @konstin, any idea? Maybe there was a recent development in pyo3 that we could leverage here?

Guide contributeur

Direction de recherche
Examinez les différences de benchmark entre hyperjson et orjson pour la sérialisation booléenne. Examinez l'approche unsafe d'orjson et explorez des alternatives sûres utilisant PyO3 ou la bibliothèque standard de Rust pour éviter les allocations.
Stack technique
pythonrust
Domaine
backend
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.
2
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-3 heures
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
PythonRust
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
50