Por qué se fusionaron pandas en python más rápido que los datos.mesa se fusiona en R en 2012?

Parece que Wes pudo haber descubierto un problema conocido en data.table cuando el número de cadenas únicas ( niveles) es grande: 10,000.

¿Revela Rprof() la mayor parte del tiempo pasado en la llamada sortedmatch(levels(i[[lc]]), levels(x[[rc]])? Esto no es realmente la unión en sí (el algoritmo), sino un paso preliminar.

Los esfuerzos recientes han ido en permitir columnas de caracteres en las claves, lo que debería resolver ese problema mediante la integración más cercana con la propia tabla hash de cadena global de R. Algunos resultados de referencia son ya reportado por test.data.table() pero ese código no está conectado todavía para reemplazar los niveles a los niveles coinciden.

¿Las fusiones de pandas son más rápidas que data.table para columnas enteras regulares? Esa debería ser una forma de aislar el algoritmo en sí frente a los problemas de factores.

También, data.tabletiene en mente combinar series temporales. Dos aspectos a eso: i) multi columna ordenado claves tales como (id,datetime) ii) rápido prevaleciente join (roll=TRUE) a.k.a. última observación llevada adelante.

Necesitaré algún tiempo para confirmar, ya que es el primero que he visto de la comparación con data.table como se presenta.

ACTUALIZACIÓN de datos.table v1.8.0 released July 2012

• Función interna sortedmatch () eliminada y reemplazada por chmatch() al hacer coincidir los niveles i con los niveles x para columnas de tipo 'factor'. Este paso preliminar estaba causando una desaceleración significativa (conocida) cuando el número de los niveles de una columna de factores fue grande (por ejemplo, >10.000). Exacerbado en pruebas de unión de cuatro columnas de este tipo, como lo demostró Wes McKinney (autor del paquete Python Pandas). Coincidencia de 1 millón de cadenas de las cuales de los cuales 600,000 son únicos, ahora se reduce de 16 a 0.5 s, por ejemplo.

También en esa liberación estaba:

• Las columnas de caracteres ahora están permitidas en las claves y son preferidas a factor. datos.table () y setkey () ya no coaccionan carácter a factor. Los factores siguen siendo compatibles. Implementos FR#1493, FR#1224 y (parcialmente) FR # 951.

• Nuevas funciones chmatch () y %chin%, versiones más rápidas de match() y %en % para vectores de caracteres. La caché de cadena interna de R es utilizado (no se construye una tabla hash). Son aproximadamente 4 veces más rápidos que match () en el ejemplo en ?chmatch.

A partir de los datos de Sep 2013.la tabla es v1. 8.10 en CRAN y estamos trabajando en v1.9.0. NOTICIAS se actualiza en vivo.

Pero, como escribí originalmente, arriba :

data.table tiene la serie temporal merge en mente. Dos aspectos a eso: i) múltiples columnas ordenado claves tales como (id, datetime) ii) prevalecer rápido join (roll=TRUE), también conocida como última observación arrastrada.

Así que la unión de Pandas equi de dos columnas de caracteres es probablemente aún más rápida que data.tabla. Ya que suena como si hash las dos columnas combinadas. datos.la tabla no hace hash con la clave porque tiene en mente las uniones ordenadas prevalecientes. Una "clave" en los datos.tabla literalmente solo el orden de clasificación (similar a un índice agrupado en SQL; es decir, así es como se ordenan los datos en RAM). En la lista está añadir claves secundarias, por ejemplo.

En resumen, la diferencia de velocidad evidente resaltada por esta prueba de columna de dos caracteres en particular con más de 10,000 cadenas únicas no debería ser tan mala ahora, ya que el problema conocido se ha solucionado.