2010-09-05 10 views
5

Tengo una aplicación de diccionario muy simple que busca y muestra. Está construido con el módulo Win32::GUI. Puse todos los datos de texto sin formato necesarios para el diccionario en la sección __DATA__. El script en sí es muy pequeño, pero con todo lo que está debajo de la sección __DATA__, su tamaño alcanza los 30 MB. Para compartir el trabajo con mis amigos, he empacado el script en un ejecutable independiente usando la utilidad PP del módulo PAR::Packer con el nivel de compresión más alto 9 y ahora tengo una aplicación de diccionario de un solo archivo sobre el tamaño de 17MB.¿Cómo formateo correctamente los datos de texto sin formato para una aplicación de diccionario Perl simple?

Pero aunque estoy muy cómodo con la idea de un script de archivo único, colocar tanta cantidad de datos de texto en la sección DATOS del script no me parece correcto. Por un lado, cuando intento abrir la secuencia de comandos en Padre (Notepad ++ está bien), que estoy recibiendo el error que es como:

Can't open my script as the script is over the arbitrary file size limit which is currently 500000.


Mis preguntas:

¿Me aporta beneficios adicionales a excepción de la eliminación del problema de apertura de archivos de Padre si muevo todo en la sección de DATOS a un archivo de texto separado?

Si lo hago, ¿qué debo hacer para reducir el tamaño del archivo por separado? ¿Lo zip y lo descomprimes mientras haces la búsqueda y la pantalla?

¿Cómo formatea normalmente la gente los datos de texto necesarios para una aplicación de diccionario?

¿Algún comentario, idea o sugerencia? Gracias como siempre :)

Respuesta

2

Si lo hago, ¿qué debo hacer para reducir el tamaño del archivo por separado? ¿Lo zip y lo descomprimes mientras haces la búsqueda y la pantalla?

Bueno, depende de POR QUÉ usted quiere reducir el tamaño. Si se trata de minimizar el uso de espacio disco (bastante extraño objetivo la mayor parte del tiempo en estos días), entonces el zip/descomprimir es el camino a seguir.

Sin embargo, si el objetivo es minimizar el uso de la memoria, un mejor enfoque es dividir los datos del diccionario en fragmentos más pequeños (por ejemplo, indexados por una primera letra) y solo cargar los fragmentos necesarios.

¿Cómo formatea normalmente la gente los datos de texto necesarios para una aplicación de diccionario?

mi humilde opinión, el enfoque habitual es lo que se obtiene como el final lógico de un enfoque mencionado anteriormente (datos indexados dividido y): utilizando una base de datos back-end, que permite sólo para recuperar los datos que es en realidad necesario.

En su caso, probablemente algo simple como archivos SQLite o Berkley DB/DBM debería estar bien.

¿Me aporta algún beneficio extra excepto la eliminación del problema de apertura de archivos de Padre si muevo todo lo que está debajo de la sección de DATOS a un archivo de texto separado?

Esto depende en cierto modo de su uso ... si se trata de un script que nunca cambia utilizado por 3 personas, puede no ser beneficios tangibles.

En general, hará que el mantenimiento sea mucho más fácil (puede cambiar el diccionario y la lógica del código de forma independiente - piense en el archivo de definiciones de virus vs. antivirus ejecutable para el ejemplo del mundo real).

También disminuirá el consumo de memoria de proceso si sigue los enfoques que mencioné anteriormente.

+1

En estos días probablemente llegue a YAML primero para almacenar datos textualmente, ya que su formato es legible y editable por los humanos, y la interfaz es muy fácil de usar y comprender (además, cualquiera que ejecute una versión razonablemente reciente de Perl ya debería tenerla). instalado). – Ether

+0

@Ether - ¿YAML ofrece búsquedas aleatorias escalables que funcionan bien? ¿O es solo un lenguaje de formato ala XML con búsquedas similares a XSLT (a 30MB, un enfoque de tipo XML + XSLT se vuelve significativamente peor que una base de datos adecuada en cuanto a rendimiento) – DVK

+1

[YAML es solo un marco de serialización.] (Http://search.cpan.org/dist/YAML/lib/YAML.pm) Si empaqueta un hash de Perl, entonces sí, proporcionará la búsqueda aleatoria adecuada. Porque es un hash. – Dummy00001

2

Dado que ya usa PAR::Packer, ¿por qué no lo mueve a un archivo o módulo separado y lo incluye en el archivo PAR?

La forma más fácil (no hay opciones de línea de comandos adicionales a pp, que verán la declaración use y hacer lo correcto):

words.pl

#!/usr/bin/perl 

use strict; 
use warnings; 

use Words; 

for my $i (1 .. 2) { 
    print "Run $i\n"; 
    while (defined(my $word = Words->next_word)) { 
     print "\t$word\n"; 
    } 
} 

Words.pm

package Words; 

use strict; 
use warnings; 

my $start = tell DATA 
    or die "could not find current position: $!"; 

sub next_word { 
    if (eof DATA) { 
     seek DATA, $start, 0 
     or die "could not seek: $!"; 
     return undef; 
    } 
    chomp(my $word = scalar <DATA>); 
    return $word; 
} 

1; 

__DATA__ 
a 
b 
c 
+0

gracias por compartirme este gran consejo :) Acabo de probar LA manera fácil que sugirió y pp hace las cosas bien! ¡Eso es genial! – Mike

+0

@Mike Todavía estoy jugando con la manera dura y correcta. Básicamente se trata de agregar '-a words.txt' a la línea' pp'. Si quiere leer todo el archivo de una vez, puede decir 'my $ words = PAR :: read_file ('words.txt');'. Todavía estoy trabajando en un método para leer las líneas una por una. Creo que implicará 'PAR :: par_handle' y [' Archive :: Zip :: MemberRead'] (http://search.cpan.org/dist/Archive-Zip/lib/Archive/Zip/MemberRead.pm) . –

Cuestiones relacionadas