optimizando tamaño en c...
ReneUK
30 de Junio del 2005
Hola,
Me gustria si alguien pudiera comentar algunos truquillos para optimizar codigo en c, entendiendo por optimizar, que ocupe menos caracterees el codigo fuente :-D, es para un concurso, la otra vez quede fatal... :-S
Algun tutorial o artÃculo bueno, que hable de cualquier tipo de optimizacion ?
Asias.
Me gustria si alguien pudiera comentar algunos truquillos para optimizar codigo en c, entendiendo por optimizar, que ocupe menos caracterees el codigo fuente :-D, es para un concurso, la otra vez quede fatal... :-S
Algun tutorial o artÃculo bueno, que hable de cualquier tipo de optimizacion ?
Asias.
PierDo
30 de Junio del 2005
Lo que puedas reducir un codigo depende de tu nivel con un lenguaje, no creo que con un truco o dos vayas a conseguir gran cosa. Debes practicar.
concurso ? de que ? pasa la url please
concurso ? de que ? pasa la url please
ReneUK
30 de Junio del 2005
pos como tengas que dominar el lennguaje lo llevo claro :(
la direccion del concurso es www.mqo.es...
la direccion del concurso es www.mqo.es...
hiei
30 de Junio del 2005
Bueno, manuales o tutoriales sobre esto no conosco (tal vez porque es algo muy dependiente del compilador usado) pero hay algunas cosas que siguen la logica de la programacion en ensamblador.
Usar el modificador register en la mallor cantidad de variables locales que se pueda (esto hara que se usen los regisros del procesador siempre que se pueda en vez de la RAM)
Evitar a toda costa el uso de cadenas de texto (estas ocupan espacio en RAM al momento de la carga)
Evitar el tipo const en las variables, preferir el #define en su lugar (una variable const en muchos casos ocupa espacio de almacenamiento efectivo)
Evitar el uso de variables intermedias. El codigo como:
int c = getc (file);
putc (c, file);
Puede ser bien reemplazado por:
putc (getc(file), file);
(Bueno, ya se que es un ejemplo estupido, pero se entiende la idea...)
Si de lo que se trata es de que el codigo ocupe menos (solo el codigo, datos dinamicos es otra cosa) preferir el uso de algunas variables mas para guardar informacion que, a pesar de poder ser calculada, sus algoritmos son complejos y costosos.
Ejemplo de esto son las listas simplemente enlazadas contra las doblemente enlazadas. En las primeras, por ejemplo, el codigo que ocupa la incercion en una pocicion determinada, es depor si largo, frente al codigo de insercion de las doblemente enlazadas que se simplifica enormemente, y solo usamos un puntero mas por nodo.
Prefiere el a = (b!=0)? b:c al
if (b!=0) a=b; else a=c;
Creeme, es mas largo (bueno, en los compiladores de borland da igual... realmente son unos estupidos los que implementaron eso)
Si devemos indicar tipos booleanos prefieramos el uso de bits en lugar del bool estandas (o un int a secas) Esto ahorra memoria de datos, pero encarece la memoria de programa al trener que enmascarar bits particulares
Modularizar el codigo a los extremos. No mezquinen en hacer funciones genericas con punteros a void*, esto es peligroso si uno no save como usarlas pero evita tener que copiar un algoritmo para distintos tipos de datos.
Ningun miedo al GOTO, en estos casos es tu amigo... (la legibilidad del codigo, vien saludos, pero creo que no importa mucho) Uno de los mejores codigos del mundo fue escrito a base de gotos (el planificador del nucleo de Linux) y no puedo decir que sea inentendible.
Existe un par de instrucciones (setjmp, longjmp) uqe sriven para hacer gotos entre funciones. A veces pueden sarlvarnos la vida en algun enrredo.
La malloria de los compiladores pueden generar el codigo ASM directamente para tu programa en C, usalo como enseñanza...
Pero por sobre todo, sentido comun, mira como de grande queda el ejecutable en cada compilacion y si pruevas algo que deveria reducir el codigo y no lo hace, bueno, prueva otra cosa...
Usar el modificador register en la mallor cantidad de variables locales que se pueda (esto hara que se usen los regisros del procesador siempre que se pueda en vez de la RAM)
Evitar a toda costa el uso de cadenas de texto (estas ocupan espacio en RAM al momento de la carga)
Evitar el tipo const en las variables, preferir el #define en su lugar (una variable const en muchos casos ocupa espacio de almacenamiento efectivo)
Evitar el uso de variables intermedias. El codigo como:
int c = getc (file);
putc (c, file);
Puede ser bien reemplazado por:
putc (getc(file), file);
(Bueno, ya se que es un ejemplo estupido, pero se entiende la idea...)
Si de lo que se trata es de que el codigo ocupe menos (solo el codigo, datos dinamicos es otra cosa) preferir el uso de algunas variables mas para guardar informacion que, a pesar de poder ser calculada, sus algoritmos son complejos y costosos.
Ejemplo de esto son las listas simplemente enlazadas contra las doblemente enlazadas. En las primeras, por ejemplo, el codigo que ocupa la incercion en una pocicion determinada, es depor si largo, frente al codigo de insercion de las doblemente enlazadas que se simplifica enormemente, y solo usamos un puntero mas por nodo.
Prefiere el a = (b!=0)? b:c al
if (b!=0) a=b; else a=c;
Creeme, es mas largo (bueno, en los compiladores de borland da igual... realmente son unos estupidos los que implementaron eso)
Si devemos indicar tipos booleanos prefieramos el uso de bits en lugar del bool estandas (o un int a secas) Esto ahorra memoria de datos, pero encarece la memoria de programa al trener que enmascarar bits particulares
Modularizar el codigo a los extremos. No mezquinen en hacer funciones genericas con punteros a void*, esto es peligroso si uno no save como usarlas pero evita tener que copiar un algoritmo para distintos tipos de datos.
Ningun miedo al GOTO, en estos casos es tu amigo... (la legibilidad del codigo, vien saludos, pero creo que no importa mucho) Uno de los mejores codigos del mundo fue escrito a base de gotos (el planificador del nucleo de Linux) y no puedo decir que sea inentendible.
Existe un par de instrucciones (setjmp, longjmp) uqe sriven para hacer gotos entre funciones. A veces pueden sarlvarnos la vida en algun enrredo.
La malloria de los compiladores pueden generar el codigo ASM directamente para tu programa en C, usalo como enseñanza...
Pero por sobre todo, sentido comun, mira como de grande queda el ejecutable en cada compilacion y si pruevas algo que deveria reducir el codigo y no lo hace, bueno, prueva otra cosa...
hiei
30 de Junio del 2005
Me olvidaba la ultima receta:
Ninguna de estas recetas son absolutas y pueden fayar (de hecho, la malloria de las veces lo hacen) pero es un buen comienzo el experimentar...
No confies en el optimizador del compilador, hazlo tu, y si puedes azlo en ASM...
Ninguna de estas recetas son absolutas y pueden fayar (de hecho, la malloria de las veces lo hacen) pero es un buen comienzo el experimentar...
No confies en el optimizador del compilador, hazlo tu, y si puedes azlo en ASM...