Html 2 txt

Community ES
21

Vale quizás he generalizado. Es que una vez dejé varias máquinas
tontas al hacer llamadas al sistema ya que llegué al maximo numero de
archivos abiertos en el sistema, y tengo muy mal recuerdo de ese
día. :wink:

22

2008/9/15 Xavier N. [email protected]

2008/9/15 Francesc E. [email protected]:

Mi experiencia me dice que si se puede evitar hacer llamadas a sistema
mejor.

Bueno, eso asi de general no lo comparto. Las llamadas a sistema son
un recurso valido en funcion de la aplicacion. Por eso existe
mini-magick, algunos tipos sospechosos generan PDF usando pdflatex,
etc. Depende.

Teoricamente, se obtiene mejor rendimiento sin hacer este tipo de
llamadas,
pero ya me he encontrado casos, en los que no es así. Por ejemplo en
jruby
existe un modulo, creo que era jrmagick o algo así, y conseguí mayor
rendimiento con las mini-magick, a las cuales les especificas como
directorio temporal un ramfs y no tiene mucho que envidiar al resto de
opciones.

Mi experiencia ha sido positiva en muchos casos, incluso rails para
enviar
emails hace algo parecido con popen(“sendmail”,“w+”) para enviar los
mails
de actionmailer.

Como siempre en estos casos, la única manera es probar. En algunos
casos,
para evitarme lios de rutas popen(%x(which sendmail)) por ejemplo.

23

2008/9/15 Guillermo [email protected]:

para evitarme lios de rutas popen(%x(which sendmail)) por ejemplo.
Pero hay que tener en cuenta muchos factores:

  • Puede que no exista la misma solucion en una libreria. Si necesitas
    un output apañado como el de elinks, suerte con strip_tags.

  • Puede que la simplicidad del codigo valga mucho mas la pena que un
    poco de perdida teorica de rendimiento. (Si esa accion es llamada 7
    veces al dia puede que te de lo mismo).

  • Podria pasar que como en el caso de elinks descargando una pagina de
    internet el tiempo este dominado por el proceso mismo y es
    despreciable con respecto al coste de system() mismo.

  • Etc.

Depende mucho, yo creo que no se puede generalizar y para cada caso
hay que determinar cual es la mejor opcion. Descartar system() por
defecto no tiene sentido. Hay que ver el caso.

24

2008/9/15 Francesc E. [email protected]:

A nivel rendimiento de aplicaciones siempre será más lento hacer llamadas a
sistema. Los de GitHub tenían problemas de rendimiento y en su blog lo
comentaron hace unos meses.

Yep lo lei. Ahi el problema es usar system() en algo con carga. No es
que system() en si sea una mala opcion, fijate que empezaron con
system() y son gente que saben lo que hacen. Pero cuando el site
empieza a tener usuarios y todo va alrededor de git, pues llega un
momento en el que system() no da mas.

25

A nivel rendimiento de aplicaciones siempre será más lento hacer
llamadas a sistema. Los de GitHub tenían problemas de rendimiento y en
su blog lo comentaron hace unos meses.

Lo dejo aquí para no caer en un off-topic.

26

2008/9/15 Francesc E. [email protected]:

A nivel rendimiento de aplicaciones siempre será más lento hacer llamadas a
sistema. Los de GitHub tenían problemas de rendimiento y en su blog lo
comentaron hace unos meses.
Lo dejo aquí para no caer en un off-topic.

Eso es una generalización que está bien tener en cuenta como pista y
estar atento a la hora de hacerlo. Pero aparte de las excepciones que
comenta Xavi, puede que simplemente no sea más lento, en algún caso
concreto. Obviamente, no puedes decir que una llamada al sistema
siempre es más lento, porque, ¿más lento que qué? Si el término de la
comparación es variable y desconocido, no puedes afirmarlo con
carácter general (por mucho que muchas veces sea así). Un ejemplo de
esto era la generación de HTML a partir de Markdown. Antes de la
aparición de alternativas como Rdiscount o Maruku, la única
implementación en Ruby era Bluecloth… que era del orden de tres
veces más lenta que hacer una llamada al sistema y usar la versión en
Perl.

Así que aunque como guía es buena, y sirve para hacer las llamadas al
sistema con cabeza, tampoco hay que grabarla en piedra, porque a veces
la llamada al sistema es simplemente la mejor
opción.

Sergio Gil Pérez de la Manga
e-mail > [email protected]
blog > http://www.lacoctelera.com/porras
now > http://twitter.com/porras