¿Por qué, en particular a partir de Android 6 (para la versión 5 no lo sé, pero seguramente no para la 4.x y menores) hay una excesiva lentitud para operaciones triviales sobre una carpeta (por ejemplo, renombrar una carpeta o pegar su contenido) cuando contiene muchos archivos muy pequeños?
Esto me parece un trágico deterioro del rendimiento del sistema. Qué tenían en mente los programadores de Google cuando diseñaron estas versiones?
Este problema se debe probablemente a que Android permite el acceso al almacenamiento interno a través de FUSE ( Sistema de archivos en USErspace ), ya que el propio almacenamiento interno no es más que un subdirectorio del /data partición.
Estas pruebas se han realizado en LineageOS 14.1 (Android 7.1.2), a través del emulador de terminal Termux, utilizando un directorio llamado test que contenía 9414 archivos cuyo tamaño oscilaba entre uno y cinco bytes. Los archivos subyacentes /data la partición fue formateada como ext4 .
No estoy afiliado ni a Termux ni a su autor.
Los comandos utilizados fueron
cd /sdcard
time cp -r test test2Que devolvió un tiempo transcurrido de
real 1m10.477s
user 0m0.595s
sys 0m3.360sEl directorio test2 se borró después de confirmar los resultados.
Los comandos utilizados fueron
su
cd /data/media/0
time cp -r test test2Básicamente, lo que hice aquí fue pasar a la /data que contiene el almacenamiento interno real. Los resultados de esta prueba son los siguientes.
0m07.06s real 0m00.14s user 0m06.18s systemDada la enorme discrepancia en el tiempo transcurrido al copiar datos en FUSE y al hacer lo mismo en ext4 directamente, asumo que el culpable es la sobrecarga generada por el propio FUSE.
Por lo que este es el elemento infractor.. por lo que es su mecanismo el que sufre cuando se está en presencia de archivos fragmentados (es decir, me refiero a que no están todos dispuestos de forma contigua en un segmento de memoria - nótese que no estoy del todo seguro de mi consideración), mientras que no hay problemas involucrados archivos individuales (pequeños o grandes) que requieren un solo bloque lineal (de hecho, para operaciones similares en, por ejemplo, archivos multimedia incluso más grandes que la carpeta infractora, se requieren tiempos muy cortos).
Increíble que el mecanismo amplifique exponencialmente la duración: en base a lo descrito, parece que al aumentar el número de elementos para los que hay que acceder, el tiempo se ve afectado exponencialmente. Muchas gracias por la aclaración.
@Bento Como dije en los comentarios, el tipo de memoria que se instala en un dispositivo móvil (eMMC), al igual que las unidades SSD, hace no sufren de fragmentación, porque no hay partes giratorias, que sí están presentes en un disco duro tradicional. En las unidades eMMC se puede acceder a cualquier bloque en prácticamente el mismo tiempo, por lo que la fragmentación es irrelevante. Sería interesante estudiar las repercusiones de utilizar el ext4 sistema de archivos, que fue diseñado pensando en los discos duros mecánicos, en las eMMC. Puede que quieras buscar el f2fs sistema de archivos, si este tema le interesa.
PreguntAndroid es una comunidad de usuarios de Android en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.
0 votos
@beeshyams Sí, lo uso. He probado con varios m. de archivos, pero siempre persiste el problema. En el pasado recibí una pista útil aquí en S.E., alguien me sugirió usar ADB. Esto resuelve eficazmente el problema, pero es un poco incómodo para utilizar el PC cada vez que tengo un tipo de carpeta, por otra parte la pregunta había permanecido: ¿por qué este cambio en el rendimiento? La referencia a los programadores GG imho no es tan fuera de contexto: En primer lugar, ¿cómo se puede afirmar una ausencia absoluta de algún programador GG o alguien en alguna relación con ellos? En segundo lugar, nada polémico, pero simplemente: ¿cuál es su objetivo?
0 votos
He encontrado lo que probablemente sea el verdadero culpable. Limpieza de comentarios en curso.