Archives de catégorie : dev

Microbenchmark: Java (Sprint Boot) memory hungry compared to Rust (Actix-web)

I ran two micro-benchmarks comparing web service endpoints implemented in Java (Sprint Boot and Spark) and Rust/Actix-web. In summary, performance were equal or not that different, but memory usage was extremely higher in Java. (disclaimer: micro-benchmarks don’t reflect more complex applications, the ease to face various specific cases, to find developers, to adapt the current infrastructure and dev ecosystem…).

Micro-benchmark 1: receive a JSON and return a subset

An overly simplistic benchmark: it does almost no computation excepted deserializing and serializing a JSON.

Java version performed between 0% and 25% slower (according to the number of concurrent calls, the more the better). But the memory consumption was 5Mo for Rust and larger than 300Mo for Java!

Micro-benchmark 2: query a Postgres DB to return the reading of a kanji

The service takes a kanji character (Japanese character of Chinese origin) as a query parameter, search in a Postgres DB all the readings associated to this kanji and return them as a JSON.

Both Java and Rust version had the same performance, the Rust one being less stable according to Apache Bench. But in term of memory… 10Mo for Rust vs 160-190 (Spark) and 258-370Mo (Spring) for Java.

If you are running an infrastructure based on Java « micro »-services, that will make quite an overhead on your hosting bill.

Openstreetmap: Generate heatmaps using Osmosis

I thought it would be nice to create heatmaps from the Openstreetmap data (i.e. for displaying the areas lacking « addr:housenumber »). I created, OsmosisHeatmap (jar file, source), a plug-in for Osmosis (a command line tool for processing Openstreetmap data) that generates a JavaScript file with the coordinates, JS that can be used by the sample HTML page based on Leaflet and Leallet.Heat.

And it gives something like that:

Problème d’affichage du texte dans Visual Studio Code sur Kubuntu 16.04? Changez de police!

Après la mise à jour de Kubuntu 15.10 à la version 16.04, le texte avait une sale tronche: il était plus sombre et avait l’air moins précis.

En fait cela venait du fait que la police par défaut était devenue « Courier New ». La solution, qui n’avait rien à voir avec la couleur du texte (!), a été de modifier le fichier de réglages (menu Fichier / Préférences / Paramètres utilisateur) en rajoutant un entrée comme:

"editor.fontFamily": "Liberation Mono"
"editor.fontFamily": "Oxygen Mono"

J’ai galéré pour trouver pourquoi cela ne touchait que Kubuntu 16.04 (que ce soit sous KDE ou XFCE), et pas Ubuntu 16.04 (sous Unity) ou Ubuntu 15.10 (sous KDE): grâce à des VM j’avais comparé (avec « strace ») les différents fichiers chargés par vscode, sans réussite: il semblait que les fichiers étaient les même, notamment les fichiers de thème de GTK 2.

En fait, j’aurais pu trouver plus rapidement en utilisant des outils de dev de vscode (ceux de Chromium; on les active dans le menu aide et on les ouvre avec F12): j’aurais pu voir quel était la police utilisée en pratique dans l’éditeur.

Text display issue in Visual Studio Code in Kubuntu 16.04? Change the font!

After upgrading Kubuntu from 15.10 to 16.04, the text really looked ugly: it was darker (even when my theme specified « #ffffff ») and looked imprecise.

In fact, the reason was the default font which was now « Courier New ». The solution, which had nothing to do with the text color (!), was to modify the configuration file (menu File / Preferences / User Settings) by adding an entry like:

"editor.fontFamily": "Liberation Mono"
"editor.fontFamily": "Oxygen Mono"

I struggled to find why it only impacted Kubuntu 16.04 (either KDE and XFCE), and not Ubuntu 16.04 (on Unity) or Ubuntu 15.10 (on KDE): using some VMs I compared (with « strace ») the files loaded by vscode, without any success: it seemed that the files were the same, including the GTK 2 themes.

In fact, I could have found more quickly by using the vscode (Chromium) dev tools (unlock them in the Help menu and press F12): I would have seen which was the font actually used by the editor.

« Lazarus: Form Recovery » makes forms submit slow :-(

« Lazarus: Form Recovery » is a Firefox add-on that saves the text of the forms so it can be restored later (very handy, for example if you have typed a long mail/message/Wikipedia contribution and something bad happens, like a crash or a computer shutdown).

Unfortunately, I realized that it causes a small delay (something like 1.5s) when submitting a form. It is perceptible in the case of an Ajax form (or even an « offline » form where nothing is sent but data is processed locally in Javascript; in this case the result should be instant). I spend some times searching around, it was crazy! No problem with a simple « onClick » but only with « onSubmit ». Was it the debug version of React? No! Or the fact that I used the Javascript compilation of React JSX? No! There was nothing special in the Performance analyser. Then I realized that Chromium was fast. And Firefox dev edition was fast. Then I began the Firefox add-on hunt…

That’s strange that saving is not asynchronous…

(by the way, if you want to compile JSX files using Node.js, don’t install « node » on Ubuntu, that’s not « Node.js »! Install « nodejs » instead, and make a symlink from « /usr/bin/nodejs » to « node » somewhere on your path. Otherwise you may ask yourself why the JSX compiler does nothing. It’s just that the executable « node » is completely unrelated)

Atom: police japonaise / Japanese font

(English below)

Dans l’éditeur de texte Atom, sous Kubuntu 15.04, les caractères japonais s’affichaient comme un carré (□), alors que les autres éditeurs (Emacs, Kate, Geany…) n’avaient pas ce problème. Pour obtenir un affichage correct, j’ai mis comme police dans les préférences «Oxygen Mono, TakaoPGothic». Par contre, comme avec les autres éditeurs de textes, les caractères japonais ne s’affichent pas avec une longueur fixe (vu que la police TakaoPGothic n’est pas une police à chasse fixe), mais ce n’est pas grave.

In the text editor Atom, in Kubuntu 15.04, the Japanese characters were displayed as a square (□), whereas the other editors (Emacs, Kate, Geany…) behave correctly. In order to obtain a correct display, I set in the settings the font as «Oxygen Mono, TakaoPGothic». However, as in the other editors, the japanese characters were not displayed with a fixed length (given that the font TakaoPGothic is proportional), but that’s not really a problem.

 

Postgresql, micro-benchmark: inserting or not a blob

Let say that I have a table with 20 non-null text columns (32 characters long), 20 non-null integers and a blob (bytea, nullable). When inserting records, what is the overhead of setting the blob? Answer: about no difference up to 80ko. From that it get slower.

Testing details: 2000 records (on 2000 transactions), inserted on 16 threads, each of them having a persistent connection. The DB server is on the same machine (Ubuntu amd64), no particular configuration.

MyKanji 0.3

J’ai écrit une petite extension pour Firefox permettant de voir dans une page les kanjis que je n’ai pas encore appris. On peut l’installer depuis cette page (pas encore vérifié par Mozilla), et les sources se trouvent sur GitHub.

Comment cela fonctionne-t-il?

  • Phase 1: installation et configuration
    • installez le module
    • mettez dans le presse-papier un texte contenant les kanjis que vous connaissez. Par exemple en faisant un export texte d’un paquet Anki, et en copiant le contenu de ce fichier texte.
    • cliquez sur le bouton «文» dans la barre d’outils.
    • dans la zone de texte, coller le texte que vous avez préparé
  • Phase 2: utilisation
    • dans une page web, sélectionnez du texte ou toute la page (control-a)
    • ouvrez le menu contextuel (clic droit) et sélectionnez «Mes Kanjis»
    • vous obtiendrez la liste des kanjis inconnus, avec leur niveau

Microbenchmark: Expat outperforms Java and libxml2 in SAX parsing

I needed an XML parser for my tests with Rust (parsing a gigantic 2Go Wikivoyage XML dump) and there is no native one. So I would need a wrapper around a C implementation. At first, I used libxml2, because it has a very appealing name it has a very convenient XmlTextReader API where you are controlling the parsing loop (no callback like in SAX).

I wondered how it compared to the StAX API of Java, and made a simplistic test printing (to /dev/null) the names of all the nodes. And surprise, StAX was way faster:

  • the StAX (openjdk-7, Ubuntu 14.04, amd64)
    • 35 seconds
    • Memory usage: 30 Mo
  • XmlTextReader API of libxml2 (2.9.1), g++ 4.8.2
    • 50 seconds
    • 3.5 Mo

Then I made tests with SAX, comparing the default Java implementation with libxml2 and finally also libexpat 2.1:

  • Java: 30s (39Mo)
  • libxml2: 34s (2Mo)
  • libexpat: 21s (180ko)

Conclusions:

  • the Java implementation seems quite good (at least in this particular scenario)
  • libexpat is quite fast, but it’s SAX and not pull-parsing (which is very convenient)
  • if you are processing huge XML files, forget about libxml2