Parece que Wes puede 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í misma (el algoritmo), sino un paso preliminar.
Se han realizado esfuerzos recientes para permitir columnas de caracteres en las claves, lo que debería resolver ese problema al integrarse más estrechamente con la tabla de hash de cadena global propia de R. Algunos resultados de referencia ya han sido informados por test.data.table(), pero ese código aún no está conectado para reemplazar los niveles por la coincidencia de niveles.
¿Los pandas se funden más rápido que data.table para las columnas enteras normales? Esa debería ser una forma de aislar el algoritmo en sí mismo frente a los problemas de los factores.
Además, data.table tiene series de tiempo merge en mente. Dos aspectos de eso: i) multi columna pedidos claves como (id, datetime) ii) unión prevaleciente rápida (roll=TRUE) a.k.a última observación transferida.
Voy a necesitar algo de tiempo para confirmar, ya que es el primero que he visto de la comparación de data.table como se presenta.
actualización desde v1.8.0 data.table publicada en julio de 2,012
- función interna sortedmatch() eliminado y reemplazado con chmatch() cuando a juego i niveles a los niveles de x para las columnas de tipo 'factor'. Este paso preliminar estaba causando una desaceleración (conocida) significativa cuando el número de los niveles de una columna de factores era grande (por ejemplo,> 10,000). Exacerbado en pruebas de unir cuatro de tales columnas, como lo demostró Wes McKinney (autor del paquete de Python Pandas). Con un millón de cadenas de las cuales , de las cuales 600,000 son únicas, ahora se reduce de 16s a 0.5s, por ejemplo.
también en que la liberación fue:
columnas de caracteres ahora están permitidos en las llaves y se prefieren a factor. data.table() y setkey() ya no fuerzan el carácter al factor . Los factores aún son compatibles. Implementa 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. El caché de cadenas interno de R es utilizado (no se construye una tabla hash). Son aproximadamente 4 veces más rápidos que que coinciden() en el ejemplo de? Chmatch.
A partir de septiembre de 2013 data.table es v1.8.10 en CRAN y estamos trabajando en v1.9.0. NEWS se actualiza en vivo.
Pero como he escrito originalmente, arriba:
data.table tiene series de tiempo se funden en mente. Dos aspectos para eso: i) multi columna pedidos claves como (id, datetime) ii) prevalecen rápidamente join (roll=TRUE) a.k.a última observación transferida.
Así que el equi pandas se unen de dos columnas de caracteres es probablemente aún más rápido que data.table. Ya que suena como hash las dos columnas combinadas. data.table no copia la clave porque tiene en cuenta las combinaciones ordenadas predominantes. Una "clave" en data.table es literalmente solo el orden de clasificación (similar a un índice agrupado en SQL; es decir, así es como se ordenan los datos en la RAM). En la lista está agregar claves secundarias, por ejemplo.
En resumen, la marcada diferencia de velocidad 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.
Mi hipótesis: porque data.table se basa en data.frame y data.frames son lentos. Y creo que la mayoría del código de combinación de pandas está en Cython. –
@JoshuaUlrich: IIRC 'data.table' simplemente hereda de' data.frame', pero depende del código C bajo el capó. – digEmAll
@digEmAll: data.frames son lentos incluso si los manipulas en C, pero nunca he visto la fuente data.table. –