GitHub révise la recherche de code à l’aide d’un nouveau moteur de recherche

GitHub a présenté sa nouvelle fonctionnalité de recherche de code, y compris une interface de recherche repensée, une nouvelle vue de code et un moteur de recherche reconstruit à partir de zéro pour être plus rapide, plus performant et mieux comprendre le code, dit Colin Merkel, ingénieur logiciel GitHub.

Notre objectif avec la nouvelle recherche de code et la nouvelle vue de code est de permettre aux développeurs de rechercher, naviguer et comprendre rapidement leur code, de mettre les informations critiques en contexte et, finalement, de les rendre plus productifs.

Selon Merkel, le nouveau moteur de recherche est deux fois plus rapide que le précédent. Il offre également plus de flexibilité en prenant en charge les requêtes de sous-chaînes, les expressions régulières et la recherche de symboles. Par exemple, vous pouvez rechercher une chaîne dans tous les dépôts appartenant à votre organisation sans avoir à les cloner au préalable :

org:my_org "string to look for"

Vous pouvez également restreindre votre requête aux fichiers écrits dans un langage ou un référentiel spécifique, exclure des chemins spécifiques ou utiliser de nombreuses possibilités supplémentaires prises en charge par la syntaxe de requête de recherche GitHub.

La nouvelle vue de code intègre la recherche avec un navigateur de fichiers et prend en charge la navigation et la navigation dans le code, permettant d’accéder aux définitions de symboles dans plus de 10 langues.

Timothy Clem, ingénieur GitHub, a fourni une aperçu détaillé de la façon dont le nouveau moteur de recherche fonctionne dans les coulisses pour atteindre ses objectifs en termes de flexibilité, de performances et d’évolutivité.

Au cœur du moteur de recherche GitHub se trouve un puissant indexeur, qui est une condition préalable pour pouvoir exécuter des requêtes rapidement. L’index de recherche est spécialisé pour le code, par exemple en étant capable de faire la distinction entre les langages de programmation, en n’ignorant pas la ponctuation, en ne supprimant pas les mots vides, etc. L’indice doit également inclure ngrammesc’est-à-dire des séquences de caractères d’une longueur donnée, pour prendre en charge les requêtes de sous-chaînes.

GitHub construit son index de recherche en analysant 45 millions de référentiels, représentant 115 To de contenu sur 15,5 milliards de documents, ce qui est une tâche ardue. Heureusement, explique Clem, deux facteurs permettent de réduire la quantité de travail à effectuer : l’utilisation des identifiants d’objets Git blob pour répartir uniformément les documents uniques sur les fragments, et le fait que GitHub héberge de nombreux contenus en double.

Lorsqu’une nouvelle requête est reçue, elle est analysée dans un arbre de syntaxe abstraite et transformée en n requêtes simultanées envoyées à des partitions distinctes dans le cluster de recherche. Les fragments effectuent un traitement de bas niveau tel que la traduction de regex en requêtes de sous-chaîne sur les indices ngram. Enfin, les fragments renvoient leurs résultats au service de requête, qui les agrège et sélectionne les 100 premiers.

Nos temps de réponse p99 à partir de fragments individuels sont de l’ordre de 100 ms, mais les temps de réponse totaux sont un peu plus longs en raison de l’agrégation des réponses, de la vérification des autorisations et de choses comme la coloration syntaxique. Une requête immobilise un seul cœur de processeur sur le serveur d’index pendant ces 100 ms, de sorte que nos 64 hôtes principaux ont une limite supérieure d’environ 640 requêtes par seconde.

Grâce à cette approche, GitHub peut réindexer l’intégralité du corpus du référentiel en 18 heures environ. La taille globale de l’index est de 25 To, soit environ le quart des données d’origine.

La nouvelle recherche de code est disponible gratuitement pour tous les utilisateurs de GitHub.