J’utilise beaucoup Kafka ces derniers temps, et dans Kafka, beaucoup de choses sont des tableaux de bytes, m\u00eame les headers !<\/p>\n
Comme j’ai de nombreux composants qui s’\u00e9changent des messages, j’ai ajout\u00e9 des headers pour aider au suivi des messages, et entre autres un header Il m’a donc fallut transformer un En cherchant un peu, Guava a une solution bas\u00e9e sur les op\u00e9rations binaires (bitwise calculation) via la classe Pour comparer les trois, rien de mieux que JMH – The Java Microbenchmark Harness<\/a>. Cet outil nous permet d\u2019\u00e9crire des micro-benchmarks pertinents en tenant compte des caract\u00e9ristiques internes de la JVM. Il offre aussi des outils int\u00e9gr\u00e9s pour analyser les performances de nos tests (profiler, disassembler, …). Si vous ne connaissez pas JMH, vous pouvez vous r\u00e9f\u00e9rer \u00e0 cet article : INTRODUCTION \u00c0 JMH \u2013 JAVA MICROBENCHMARK HARNESS<\/a>.<\/p>\n Tout d’abord, j’ai configur\u00e9 le benchmark avec un State au Thread pour que le setup soit jou\u00e9 pour chaque Thread. Entre autre, je cr\u00e9\u00e9 un Ensuite, j\u2019impl\u00e9mente une m\u00e9thode de benchmark pour chaque mani\u00e8re de convertir un Le benchmark complet est accessible ici<\/a>.<\/p>\n Tous les tests ont \u00e9t\u00e9 ex\u00e9cut\u00e9s sur mon laptop : Intel(R) Core(TM) i7-8750H 6 coeurs (12 avec hyperthreading) – Ubuntu 19.10.<\/p>\n La version de Java utilis\u00e9 est Premi\u00e8re constatation : mon intuition \u00e9tait bonne, instancier une D’une mani\u00e8re surprenante Kafka, qui est connu pour sa performance, a une impl\u00e9mentation plus lente que Guava ou que celle via un Les r\u00e9sultats obtenus via Laissons de c\u00f4t\u00e9 l’impl\u00e9mentation via une Pour cela je vais utiliser les capacit\u00e9s de profiling de JMH via l’option Si on profile les allocations m\u00e9moire via On voit bien l\u2019int\u00e9r\u00eat de la r\u00e9utilisation du Par contre, les allocations m\u00e9moires sont proches pour les trois autres impl\u00e9mentations, cela ne nous donne donc pas beaucoup plus d’informations.<\/p>\n Essayons maintenant de profiler le CPU avec Les r\u00e9sultats ne sont pas facilement compr\u00e9hensibles (pour les voir c’est ici<\/a>), quelques constatations :<\/p>\n Pour finir, par curiosit\u00e9, j’ai \u00e9t\u00e9 regarder le code de Attention \u00e0 ce que vous mesurez, l’impl\u00e9mentation via une La r\u00e9utilisation d’un Follow the force, read the code ;)<\/p>\n Bien que JMH soit un super outil, il faut des comp\u00e9tences techniques et beaucoup de temps pour analyser totalement ses r\u00e9sultats. M\u00eame si les diff\u00e9rences constat\u00e9es ne sont pas totalement expliqu\u00e9es; je suis quand m\u00eame content de ma petite exp\u00e9rimentation ;)<\/p>","protected":false},"excerpt":{"rendered":" J’utilise beaucoup Kafka ces derniers temps, et dans Kafka, beaucoup de choses sont des tableaux de bytes, m\u00eame les headers ! Comme j’ai de nombreux composants qui s’\u00e9changent des messages, j’ai ajout\u00e9 des headers pour aider au suivi des messages, et entre autres un header timestamp qui a comme valeur System.currentTimeMillis(). Il m’a donc fallut transformer un long en tableau de byte; d’une mani\u00e8re tr\u00e8s na\u00efve, j’ai cod\u00e9 \u00e7a : String.valueOf(System.currentTimeMillis()).getBytes(). Mais instancier une String \u00e0 chaque cr\u00e9ation de header…timestamp<\/code> qui a comme valeur System.currentTimeMillis()<\/code>.<\/p>\nlong<\/code> en tableau de byte; d’une mani\u00e8re tr\u00e8s na\u00efve, j’ai cod\u00e9 \u00e7a : String.valueOf(System.currentTimeMillis()).getBytes()<\/code>. Mais instancier une String<\/code> \u00e0 chaque cr\u00e9ation de header ne me semble pas tr\u00e8s optimale!<\/p>\nLongs<\/code>, ainsi que Kafka via son LongSerializer<\/code>. On peut aussi utiliser un ByteBuffer<\/code> pour r\u00e9aliser la conversion.<\/p>\nLe benchmark<\/h2>\n
ByteBuffer<\/code> par thread pour comparer une impl\u00e9mentation avec et sans r\u00e9-utilisation du buffer.<\/p>\n\n@State(Scope.Thread)\n\/\/ other JMH annotations ...\npublic class LongToByteArray {\n private static final LongSerializer LONG_SERIALIZER = new LongSerializer();\n\n long timestamp;\n ByteBuffer perThreadBuffer;\n\n @Setup\n public void setup() {\n timestamp = System.currentTimeMillis();\n perThreadBuffer = ByteBuffer.allocate(Long.BYTES);\n }\n\n \/\/ benchmark methods\n}\n<\/pre>\nlong<\/code> en byte[]<\/code>. J’ai impl\u00e9ment\u00e9 deux algorithmes diff\u00e9rents pour ByteBuffer<\/code> : l’un avec une instanciation d’un buffer \u00e0 chaque conversion, et l’autre avec un recyclage d’un buffer existant en utilisant le ByteBuffer<\/code> instanci\u00e9 dans la phase de setup du benchmark.<\/p>\n \n@Benchmark\n public byte[] testStringValueOf() {\n return String.valueOf(timestamp).getBytes();\n }\n\n @Benchmark\n public byte[] testGuava() {\n return Longs.toByteArray(timestamp);\n }\n\n @Benchmark\n public byte[] testKafkaSerde() {\n return LONG_SERIALIZER.serialize(null, timestamp);\n }\n\n @Benchmark\n public byte[] testByteBuffer() {\n ByteBuffer buffer = ByteBuffer.allocate(Long.BYTES);\n buffer.putLong(timestamp);\n return buffer.array();\n }\n\n @Benchmark\n public byte[] testByteBuffer_reuse() {\n perThreadBuffer.putLong(timestamp);\n byte[] result = perThreadBuffer.array();\n perThreadBuffer.clear();\n return result;\n }\n<\/pre>\nLes r\u00e9sultats<\/h2>\n
openjdk version "11.0.7" 2020-04-14<\/code>.<\/p>\n\nBenchmark Mode Cnt Score Error Units\nLongToByteArray.testByteBuffer avgt 5 4,429 \u00b1 0,204 ns\/op\nLongToByteArray.testByteBuffer_reuse avgt 5 5,655 \u00b1 0,793 ns\/op\nLongToByteArray.testGuava avgt 5 6,422 \u00b1 0,428 ns\/op\nLongToByteArray.testKafkaSerde avgt 5 9,103 \u00b1 1,515 ns\/op\nLongToByteArray.testStringValueOf avgt 5 39,660 \u00b1 4,372 ns\/op\n<\/pre>\n
String<\/code> pour chaque conversion est tr\u00e8s mauvais, 4 \u00e0 10 fois plus long que toutes les autres impl\u00e9mentations. Quand on regarde le r\u00e9sultat de la conversion, on comprend pourquoi. En utilisant une String<\/code> on ne convertit plus un nombre sur 64bit mais une cha\u00eene de caract\u00e8res o\u00f9 chaque caract\u00e8re (chaque chiffre du nombre) est cod\u00e9 sur un byte. Donc on ne compare pas exactement la m\u00eame chose puisque le r\u00e9sultat de la conversion via une String<\/code> va donner un tableau de 13 bytes, alors qu’un Long<\/code> est encod\u00e9 en 8 bytes, ce que nous donne bien la conversion via Guava, Kafka ou un ByteBuffer.<\/p>\nByteBuffer<\/code>.<\/p>\nByteBuffer<\/code> sont surprenants, l’instanciation d’un ByteBuffer<\/code> pour chaque conversion est plus performante que la r\u00e9utilisation d’un existant (qui n\u00e9cessite un clean du buffer).<\/p>\nAnalyse un peu plus pouss\u00e9e<\/h2>\n
String<\/code> et essayons de mieux comprendre les diff\u00e9rences entre les autres impl\u00e9mentations.<\/p>\n-prof<\/code>.<\/p>\n-prof gc<\/code> on a les r\u00e9sultats suivants :<\/p>\n\nLongToByteArray.testByteBuffer \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 avgt 5 4,492 \u00b1 0,708 ns\/op\nLongToByteArray.testByteBuffer:\u00b7gc.alloc.rate\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 avgt 5 4635,903 \u00b1 712,889 MB\/sec\nLongToByteArray.testByteBuffer_reuse \u00a0 \u00a0 \u00a0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 avgt 5 5,798 \u00b1 1,139 ns\/op\nLongToByteArray.testByteBuffer_reuse:\u00b7gc.alloc.rate avgt 5 \u2248 10\u207b\u2074 MB\/sec\nLongToByteArray.testGuava\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 avgt 5 6,939 \u00b1 0,899 ns\/op\nLongToByteArray.testGuava:\u00b7gc.alloc.rate\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 avgt 5 3000,818 \u00b1 376,613 MB\/sec\nLongToByteArray.testKafkaSerde \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0\u00a0 avgt 5 9,317 \u00b1 0,842 ns\/op\nLongToByteArray.testKafkaSerde:\u00b7gc.alloc.rate \u00a0 \u00a0 \u00a0 avgt 5 4467,791 \u00b1 405,897 MB\/sec\n<\/pre>\n
ByteBuffer<\/code> : il n’y a aucune allocation m\u00e9moire, alors qu’en cr\u00e9ant un nouveau buffer pour chaque conversion, on a 4 GB\/s d’allocation m\u00e9moire !<\/p>\n-prof perf<\/code> qui va utiliser l’outil perf pour profiler l’application.<\/p>\nByteBuffer<\/code> semble impliquer beaucoup plus de branches CPU, c’est peut-\u00eatre la cause de la diff\u00e9rence de performance.<\/li>\n\nHeapByteBuffer.putLong()<\/code>, c’est l’impl\u00e9mentation utilis\u00e9e via ByteBuffer<\/code> car je ne fais pas d’allocation directe. Celle-ci utilise une m\u00e9thode Unsafe.putLongUnaligned()<\/code>. Unsafe<\/code> est connu pour ses impl\u00e9mentations hautement performantes (mais ne doit pas \u00eatre utilis\u00e9 par tout le monde), ici, de plus, cette m\u00e9thode est annot\u00e9e par @HotSpotIntrinsicCandidate<\/code>code>@HotSpotIntrinsicCandidate<\/code<\/a> ce qui veut dire qu’un intrinsic<\/strong> existe certainement pour elle et peut expliquer sa diff\u00e9rence de performance avec les autres impl\u00e9mentations. Un intrinsic<\/strong> peut \u00eatre vu comme un bout de code natif, optimis\u00e9 pour votre OS \/ architecture CPU, que la JVM va substituer \u00e0 l’impl\u00e9mentation Java de la m\u00e9thode selon certaines conditions.<\/p>\nConclusion<\/h2>\n
String<\/code> ne g\u00e9n\u00e8re pas le m\u00eame tableau de bytes que les autres, et est donc beaucoup moins performante.<\/p>\nByteBuffer<\/code> n’est pas toujours la meilleure solution, car le co\u00fbt de recyclage n’est pas anodin. Les allocations sont peu co\u00fbteuses au sein de la JVM, et parfois il vaut mieux allouer qu’ex\u00e9cuter plus d’instructions.<\/p>\n