GitHub introdujo una nueva función de búsqueda de código, que incluye una interfaz de búsqueda rediseñada, una nueva vista de código y un motor de búsqueda reconstruido desde cero para que sea más rápido y más capaz, y para comprender mejor el código. Él dice Ingeniero de software de GitHub Colin Merkel.
Nuestro objetivo con la nueva investigación de código y la visualización de código es permitir que los desarrolladores encuentren, naveguen y comprendan rápidamente su código, pongan información importante en contexto y, en última instancia, lo hagan más productivo.
Según Merkel, el nuevo buscador es el doble de rápido que el anterior. También proporciona más flexibilidad para admitir consultas de subcadenas, expresiones regulares y búsqueda de símbolos. Por ejemplo, puede buscar una cadena en todos los repositorios de su organización sin tener que clonarla de antemano:
org:my_org "string to look for"
También puede limitar su consulta a archivos escritos en un idioma o repositorio específico, excluir ciertas rutas o usar las muchas posibilidades adicionales admitidas por la sintaxis de consulta de búsqueda de GitHub.
La nueva vista de código integra la búsqueda con un explorador de archivos y es compatible con la navegación y navegación de código, lo que permite saltar a definiciones de código en más de 10 idiomas.
El ingeniero de GitHub, Timothy Clem, proporcionó un Resumen detallado Acerca de cómo funciona el nuevo motor de búsqueda entre bastidores para lograr sus objetivos en términos de flexibilidad, rendimiento y escalabilidad.
En el corazón del motor de búsqueda de GitHub se encuentra un potente indexador, que es un requisito previo para poder ejecutar consultas rápidamente. El índice de búsqueda se especializa en el código, por ejemplo, al poder diferenciar entre lenguajes de programación, no ignorar la puntuación, no eliminar palabras vacías, etc. Debe incluir el índice también ngcualquier secuencia de caracteres de una longitud determinada, para admitir consultas de subcadena.
GitHub construyó su índice de búsqueda mediante el análisis de 45 millones de repositorios, lo que equivale a 115 terabytes de contenido en 15.500 millones de documentos, lo cual es una tarea abrumadora. Afortunadamente, explica Clem, dos factores hacen posible reducir la cantidad de trabajo requerido: el uso de identificadores de objetos de blob de Git para distribuir uniformemente documentos únicos en fragmentos y el hecho de que GitHub aloja una gran cantidad de contenido duplicado.
Cuando se recibe una nueva consulta, se analiza en un árbol de sintaxis abstracta y se convierte en norte Las solicitudes sincrónicas se envían a las distintas partes del conjunto de búsqueda. Los fragmentos pasan por un procesamiento de bajo nivel, como traducir la expresión regular en consultas de subcadena en punteros de ngram. Finalmente, los fragmentos devuelven sus resultados al servicio de consultas, que los agrega y selecciona los 100 principales.
Nuestros tiempos de respuesta p99 de fragmentos individuales son del orden de 100 ms, pero los tiempos de respuesta generales son un poco más largos debido a la agrupación de respuestas, la verificación de permisos y cosas como el resaltado de sintaxis. La consulta llega a un núcleo de CPU en el servidor de índice durante 100 ms, por lo que nuestros 64 hosts tienen un límite superior de aproximadamente 640 consultas por segundo.
Gracias a este enfoque, GitHub puede volver a indexar toda la colección del repositorio en unas 18 horas. El tamaño total del índice es de 25 terabytes, que es aproximadamente una cuarta parte de los datos originales.
Encontrar el nuevo código está disponible gratuitamente para todos los usuarios de GitHub.
“Orgulloso adicto al café. Gamer. Introvertido incondicional. Pionero de las redes sociales”.