Shell: seria interesante que pases el link del archivo de texto que usaste para hacer las pruebas así podemos probar cada uno en la configuración local.

No tengo inconveniente. Me parece mejo así. Incluso se pude usar como ejercicio para programar. Estuve probando otras cosas.

Subo el archivo a Dropbox para compartirlo con la comunidad y como solo es un archivo de texto aunque contiene todo el árbol de directorios del lugar,
si un usuario quiere bajar algo de ahí, tendrá que buscarlo por la red y es cosa del usuario, con este archivo no se va a poder bajar otros contenidos,
solo va a conocer lo que existe pero no contiene enlaces. ( Tampoco es que sea tan difícil pero es cosa de cada uno ), mi idea
es compartir para aprender a mejorar y conocer.

Archivo filelist.zip para pruebas.

Recordar. Archivo comprimido 20M, descomprimido 150M.

Me gustaría comentar esto y a ver que me decís.

Estuve intentando verlo desde el lenguaje Python ( que hace mucho tiempo que no toco ).
Me dio error de lectura por problema de "codificación" del texto.

Fui a la consola de Linux y use el comando file para saber algo del archivo, su respuesta fue esta:

filelist.txt: Non-ISO extended-ASCII text

Para poder leerlo desde Python3 usé algo como esto:

Código:

#!/usr/bin/env python3

def main():
    ruta = '/home/usuario/Descargas/filelist.txt'
    with open(ruta, mode='r', encoding='latin-1') as archivo:
        print (archivo.read())

if __name__=='__main__': main()

Según parece la codificación "ISO-8859-1" es igual a "latin1", me funcionó igual  especificando uno de estos dos.
Se supone que cuando leemos un archivo "deberíamos" especificar como está codificado ya que por defecto
nuestro sistema posiblemente sea "utf-8". (Esto debería aplicarse a cualquier lenguaje).

Ahora voy a Gambas. Nuestra instrucción File.Load, no aparenta una necesidad de especificar la codifcación del archivo
para cargarlo. Cuando muestro desde Gambas (salida a la terminal) ó un archivo ejecutable que ejecuto en la terminal,
me muestra todo el contenido del archivo línea por línea. Pero tengo problemas de mostrarlo en la consola de Gambas.
¿ Por ?.

Supongamos que ejecuto este programa en Gambas.

Código:

Public Sub Ejemplo1()
 
  Dim ruta As String
  Dim texto As String
  Dim linea As String
  Dim t As Float

  ruta = User.Home &/ "Descargas/filelist.txt"
  t = Timer

  texto = File.Load(ruta)
  For Each linea In Split(texto, "\n")
    Print linea
  Next
  Print "Tiempo de carga y muestra: " & Format(Timer - t, "0.#####" & "s")

Catch
  Print "Error: " & Error.Text
 
End

Lo hice de esta forma para dar a conocer los problemas de la codificación de este archivo. Recordar que es un archivo de texto
pero que para leerse en un Amiga. Que en un Pc también lo leemos.

Continuo. Si muestro el texto de la consola de Gambas, veremos que el carácter de final aparece un carácter extraño, parece un "castillo".



Es muy probable que Gambas3 no acabe de mostrar todo el contenido en la consola por estos caracteres finales.
Entonces como ahora conocemos que hay una codificación, cambiemos la línea que muestra "linea" por esto.

Código:

 Print Conv(linea, "ISO-8859-1", "utf-8") 

Ya no mostrará ese "castillo".

Hay momentos que deja de mostrarse el contenido en la consola, lo que hago es con el ratón subir o bajar con el cursor la ventana
donde se muestra el contenido de la consola de Gambas y ese vuelve a mostrarse, incluso ya llega hasta el final.

¿ Se satura la consola de Gambas ?.

Podemos usar la opción del menú de Gambas en Depuración, usar emulador de terminal, pero esto nos hace olvidar
la posibilidad de que el archivo pueda estar codificado. Lo muestra sin pensárselo.

Recordar que el pc se calienta cuando trabaja con un archivo largo si lo muestras línea a línea.

Esto es lo que me muestra al final de la ejecución, llegando correctamente al final del archivo.

08/05/18|6318789|Commodore Amiga - Latest Public DATS Combined (TOSEC-v2018-07-27).zip

Tiempo de carga y muestra: 19,56704s

Saludos

Abriendo terminal desde el menú de herramientas y ejecutando el ejecutable creado.

Tiempo de carga y muestra: 10,36255s

Usando el emulador de terminal desde el menú de depuración: ( No puedo usar copiar y pegar ).
 

 
16,27598s

Desde la consola.  Ctrl + Alt + F1 y buscar el lugar donde se encuentra el ejecutable y ejecutar.

296,67021s

Las líneas de texto al ser un tamaño de letra grande no se ajusta. Supongo que pierde de alguna forma aceleración.

Las pruebas fueron creadas en Linux Mint 20.1

Saludos

Estoy trabajando con archivos que no son muy extensos pero que no tienen salto de linea y en gedit se queda detenido un rato largo.
Saludos.

Estoy trabajando con archivos que no son muy extensos pero que no tienen salto de linea y en gedit se queda detenido un rato largo

No es muy normal que no tengan salto de línea, ¿ no ?.
Es como confundir al editor.

Saludos

No es muy normal que no tengan salto de línea, ¿ no ?.

Es el formato que codifica gambas con el método JSON.Encode(), ni un solo salto de linea.
Saludos.

Buenas!.

Estuve retomando la carga del archivo de texto largo. Leer algo en Python me devolvió a Gambas.
Así que volví a ver el ejemplo y recordemos que el archivo estaba codificado como latin1. Esto no es realmente necesario
para comprobar si mostrar el archivo de texto en el control TextArea tarda menos tiempo o más.

Se me volvió a hacer eteeeeeerna la carga en el textarea mientras va convirtiendo cada línea de este a utf-8.
¿ Existe un control más rápido que TextArea para mostrar un archivo de texto grande ?.
Bueno, os cuento como lo solucioné. A modo de prueba.

Me acordé de GridView y su evento Data. Que por cierto ahora para poder ver la ayuda sobre un control en Gambas, hay que ser más
concreto con el botón derecho del ratón.

Os mando una captura, en realidad es el tiempo que tarda en cargar el archivo, asignarlo a una variable de cadena y decirle al GridView
cuantas filas va a tener el control. Recordemos que el archivo mide 144MB.



Y el código sencillo.

Código:

Private texto As New String[]

Public Sub Form_Open()

  With tbEjemplo
    .Header = tbEjemplo.Horizontal
    .Columns.Count = 1
    .Columns[0].Title = "Nombres de los archivos"
    .Columns[0].Alignment = Align.Left
  End With

End

Public Sub btnCarga_Click()

  Dim cadena As String
  Dim t As Float

  Dialog.Title = "Selecciona un archivo de texto"
  Dialog.Filter = ["*.txt", "Archivos de texto"]
  Dialog.Path = User.Home &/ "Descargas"
  If Dialog.OpenFile() Then Return
  t = Timer
  cadena = File.Load(Dialog.Path)
  texto = Split(cadena, gb.NewLine)

  tbEjemplo.Rows.Count = texto.Count

  Me.Title = "Tiempo de carga: " & Format(Timer - t, "0.#####" & "s")

Catch
  Message.Info("Se ha generado algún error.")

End

Public Sub tbEjemplo_Data(Row As Integer, Column As Integer)

  tbEjemplo[Row, 0].Text = Conv(texto[Row], "latin1", "utf-8")

  'tbEjemplo[Row, 0].Text = texto[Row] 'En el caso de no existiera conversión de codificación de caracteres de las líneas del texto y fuese utf-8 por defecto
  'tbEjemplo.Columns[0].Width = -1 'Ancho automático. Ralentiza el proceso demasiado para mostrar el contenido

End

Es instantáneo. El enlace del archivo de pruebas lo tenéis más arriba. Si os atrevéis a bajarlo, este pesa 143M .
 

---

Se me ocurre también:

¿ Es posible partir el archivo de texto en diferentes partes ?.

Mi idea es que cada parte sea un archivo con un tamaño máximo de 64KB (por decir un tamaño) y que luego el editor vaya leyendo cada uno de estos
archivos en orden, cuando se llega al final o al principio de cada archivo el editor sabe en todo momento que archivo tiene abrir para mostrar,
aunque se le diga al usuario que está leyendo el archivo principal.

Supongamos que el archivo se llama "economía.txt" y es grande. Si midiese 256KB.
Pues tendríamos 4 archivos de 64KB cada uno.

economía1.txt. hasta economía4.txt

De esa forma el editor no se quedaría tanto tiempo bloqueado por la carga.

Saludos

Archivos adjuntos

---

MostrarArchivo-0.0.2.tar.gz (Tamaño: 13 KB Descargas: 4)

Hola, Shell:
Estupenda solución.
Yo tuve ese problema hace tiempo y subí una comparativa de velocidad de varios controles en el otro foro. Si lo encuentro, lo subo.

---

https://foro.gambas-es.org/viewtopic.php...&highlight=

Me autocito de aquel entonces:

 

No sé si este comentario va en este foro, pero bueno.
Pues a raíz de lo preguntado sobre descomprimir y al cargar ese texto en diversos controles, me he dado cuenta de la enorme diferencia del tiempo de carga entre unos y otros. He hecho una prueba con dos archivos. Uno que comprimido pesaba 11,2M y expandido 48,7 M (120.000 registros); el otro 350k y 1,6 M expandido. Y como salidas, la salida directa a consola con debug, y los controles Editor, TextEdit y TextArea. Los resultados en segundos están en la siguiente «tabla» —que a ver si alguien me indica como introducir una tabla en condiciones, que a mí me salen estas chauzas   —:

    
..............11,2/48,7 M......0,35/1,6 M
Debug...........9,3..............0,35
Editor..........1,5..............0,02
TextEdit.|......1,6..............1,26
.........|....998...............14,00
TextArea.....1093,7.............45,02

La forma de medirlo ha sido:

Código:

  'Debug tDes
  TextoSalida.Text = tDes
  Tac = [url=http://gambaswiki.org/wiki/lang/timer]Timer[/url]
  [url=http://gambaswiki.org/wiki/lang/print]Print[/url] Tac - Tic

En el caso de TextEdit el paso de valor ha sido rápido, pero la carga del componente casi tan lenta como en el caso de TextArea y por eso aparecen dos valores. ¡Hala! Y ahora, a devanarse los sesos de porqué es así  
Puedo suponer que, aunque Editor tenga que comprobar la sintaxis, carga directamente el texto sin tener en cuenta saltos y ajustes de línea que sí tienen que hacer los otros dos. Y puedo suponer que TextArea hace los ajustes conforme se le asigna el contenido, mientras que TextEdit los hace después. Pero vamos, que digo yo.

Grandamakulo:

Gracias por el enlace, no lo conocía. La próxima vez debo recordar buscar en los dos foros.

La idea de Julio de solo leer una cantidad de lineas puede ser también una solución, aunque habría que controlar
más detalles para eso.

Al control gridview se le puede desactivar el aspecto de rejilla y casi puede parecer un control de TextArea
y ademas se puede editar. En realidad al final no son más que registros. Fecha, tamaño, nombre y su separador.
Cuando convirtieron la base de datos a un archivo de texto o csv, el archivo creado fue un tocho.

Saludos