FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Al incluir un Uses ¿se carga todo a memoria?
Hola
La duda es la expresada en el título, no he encontrado en la ayuda de delphi (o no he sabido buscar) algo que me indique cómo es la repercusión de incluir uses muy extensos para solo usar una o dos funciones de los mismos. Por ejemplo, creo recordar que en este foro alguien mencionó que no era conveniente incluir la libería DateUtils para usar solo la función IsLeapYear, pero alguien más le refutó diciendo que Delphi no carga toda la librería, solo la parte que se ocupa. La duda ha resurgido por que alguien me solicita hacer una unidad con varias decenas de funciones y que ahí todos vayamos agregando las funciones que vayamos haciendo en nuestros proyectos y luego la podremos incluir en cada uno de ellos, y no estamos seguros si eso sea conveniente, es decir, tener una unidad que con el tiempo irá creciendo cada vez más para solo usar unas pocas funciones que la mayoría no son de más 20 lineas, queremos documentarnos sobre ello. gracias por la información que puedan aportarme Saludos |
#2
|
||||
|
||||
Tengo entendido (pido que me corrijan si me equivoco por favor) de que el compilador sólo añade las referencias de las funciones y/o procedimientos que se emplean de cada unit que se añada.
Ahora me queda la duda si es conveniente de que sigan ampliado una misma unit. Es "peligroso" realizar este proceso, sobre todo si las funciones y/o procedimientos no poseen Alta Cohesión entre ellas. Lo más conveniente es que reestructuren el diseño de dicha unit para garantizar una mejor Alta Cohesión y a su vez esto les permitirá llegar a un Bajo Acoplamiento. Saludos, |
#3
|
|||
|
|||
Eso es precisamente lo que no nos agrada, esta persona esta acostumbrada a trabajar así, con una unit a manera de repositorio de utilerias genéricas (una función que regrese un dataset de un Excel, una función que abra un data set, otra que ejecute un query, etc, etc) y no nos convence eso.
Voy a documentarme sobre las referencias específicas que mencionas para poder descartar un problema por ese lado, voy a tratar de convencer de que en lugar de tener esta unit con funciones de todo tipo, hacer varias conforme la esencia de cada una de ellas; aunque me sigue quedando la duda sobre la utilidad real de una unit de operaciones de bases de datos, y digo, un método para abrir un DataSet mandado de parámetro o ejecutar un query, buscar un registro, etc, no sé exactamente que ta bueno sea, ya que en cada método hay que crear el objeto DataSet, configurarlo, hacer lo que se tenga que hacer y regresar un valor que sea usado en un evento donde también se tuvo que crear una variable DataSet y todo eso. No se por que no trabajar con componentes en un datamudule como lo hemos hecho tradicionalmente. A lo mejor yo soy el que no ve la "ventaja" que esto me puede ofrecer, por ello mismo me trato de informar Gracias |
#4
|
||||
|
||||
El tema de la unidad DateUtils es muy particular. Si te fijas, toda la unidad se basa en FormatDatetime, EncodeDateTime y DecodeDatetime, el resto.... y mira la cantidad de funciones que hay, se llaman entre sí y de forma escalonada.
Sólo quieres usar una función, pero si de forma escalonada se ejecutan 10 funciones, obviamente, las 10 funciones irá en el ejecutable final. Sobre crear tus propias bibliotecas, bueno, es inevitable, pero más vale que sigas un esquema como la vcl, en mi caso: lpDateUtils (LP = Lepes) lpForms lpClasses lpconstantes (saltolinea, saltoCarro, etc) lpTipos (excepciones personalizadas, etc). Los casos que explicas no veo necesario crear unidades, pero, por ejemplo, todos tenemos una función llamada: function Createqry(sql:string):TQuery o ¿no? Saludos
__________________
Si usted entendió mi comentario, contácteme y gustosamente, se lo volveré a explicar hasta que no lo entienda, Gracias. |
#5
|
||||
|
||||
[Paréntesis]
No lo puedo creer. Sé que nunca has mencionado tu nombre real en estos foros amigo Lepe, pero, no me vas a decir que incluso en el prefijo de tus funciones y librerías usas Lepe. [/Paréntesis] // Saludos |
#6
|
||||
|
||||
Si no me equivoco, el compilador de Delphi tiene una opcion en el proceso de compilacion de eliminacion de codigo muerto, es decir, que elimina todos los objetos y funciones no utilizados, asi se reduce el tamaño del ejecutable. Esa opcion en los compiladores de C de Borland esta OFF por defecto, mira si la encuentras en Delphi y como esta...
|
#7
|
|||
|
|||
Cita:
mmmmmmmmmmmmmmm, no, no todos ¿Qué ventaja me da tener esa función en una librería a tener un componente TQuery? , digo, igual voy a configurarlos, ya sea con parámetros o desde código. ¿ahorro de código?, igual voy a definir variables tipo TQuery o TDataSet para recibir esa función, no le veo la utilidad real |
#8
|
|||
|
|||
Hola...
Cita:
No es lo mismo hacer:
A tener algo como:
Ves la diferencia? Me ahorré declarar 2 variables y re-escribir bastante código... Saludos... |
#9
|
||||
|
||||
No puedes afirmar eso, has estado ausente mucho tiempo
Cita:
CreateQry la uso cuando necesito temporalmente ejecutar una sentencia SQL, pero no quiero tener un TQuery en el Datamodule o en el TForm sólo para una llamada, al final acaba estorbando más que ayudando, por eso uso la rutina que crea, configura la consulta y opcionalmente la ejecuta:
Muchas veces necesitas una consulta de forma puntual, sólo para actualizar un registro, etc. Tener que poner un TQuery en la ventana (o datamodule), configurarlo, ponerle nombre, y por último llamarlo desde código es "perder el tiempo", "ExecSql" son 7 letras más el SQL y listo . Saludos
__________________
Si usted entendió mi comentario, contácteme y gustosamente, se lo volveré a explicar hasta que no lo entienda, Gracias. |
#10
|
||||
|
||||
Cita:
Pero a ver, para que no se diga que nada más ando en este hilo fuera de tema les voy a dar mi opinión: no estoy de acuerdo. El ejemplo de mayenes (quien me debe una cerveza desde hace tiempo) no me convence de la necesidad de CreateQuery. Esas dos Queries que construye, ¿por qué no están en un DataModule? Si estuvieran ahí en primera instancia, ahorraría todavía más código. Ahora, para una consulta puntual, también se puede tener una Query genérica para eso. Porque, si sólo se tiene una consulta puntual en todo el código, haber definido una función es más trabajo del necesario, así que asumo que se trata de varias consultas puntuales, pero, como digo, para ello se puede usar un query genérico. Al final de cuentas, creo, el punto está en, ¿por qué queremos construir componentes Query por código? pd: lo digo un poco por molestar, pero es que no me han convencido. // Saludos |
#11
|
||||
|
||||
Creo que se han desviado del tema central.
|
#12
|
|||
|
|||
Cita:
No me acordaba Y sobre mi ejemplo, en realidad fue algo que escribí así de bote pronto... y bueno... para mi si es práctico, por que solo creas el objeto al momento de usarlo, ejecutas el query, obtienes el resultado y lo liberas de la memoria... Ahora, yo mayormente uso Interbase/Firebird y los componentes IBX, y estoy tienen un componente llamado TIBSQL el cual es más ligero en memoria, y para queries donde solo necesito obtener un valor rapidamente son mejores. Cita:
|
#13
|
|||
|
|||
Algo raro en estos foros...
Saludos |
#14
|
||||
|
||||
Roman... por favor!!. en fin, que tendré explayarme....
Cuando tienes un query en un datamodule para reusarlo en diversas ocasiones, pronto te das cuenta que si "tal ventana está abierta, puede estar usando dicha consulta, si ahora abres otra ventana que reutiliza el mismo query, podrías tener problemas" (ejem, aplica la ley de murphy ), si tienes una aplicación SDI tienes que pensar el orden de creación de ventanas y en qué orden se van a mostrar para que no se solapen dos ventanas que usan el mismo TQuery. Si tienes una MDI no queda otra que usar otra consulta genérica... y ya son dos TQuerys creadas desde el inicio del datamodule hasta que se destruya (en el mejor de los casos). Ventajas de usar el CreateQry: - Menos tiempo de diseño en configurar propiedades: El IDE es muy bueno y bonito, pero repetir tareas es una lata: asignar database, sql, sessionName , poner el TQuery en un sitio que no moleste - Algo más eficiente con la RAM: sólo está creado el tiempo estrictamente necesario. Inconvenientes: - Tener que añadir el "uses", eso si que es un coñazo Saludos.
__________________
Si usted entendió mi comentario, contácteme y gustosamente, se lo volveré a explicar hasta que no lo entienda, Gracias. |
#15
|
||||
|
||||
Cita:
Lepe + cualquier pedacitos de papel para diagramas y apuntes + CreateQry = rácano y vago. Saludos, |
#16
|
||||
|
||||
Desde luego, tener varias ventanas disponibles para un mismo proceso, cambia muchas cosas del diseño, entre las cuales está la de crear objetos Query durante la ejecución. Pero no todos los sistemas son así y en muchos casos crear un query en ejecución no es necesario. Por otra parte, la ínfima memoria utilizada para mantener un query genérico en un datamodule, difícilmente puede considerarse una ventaja por sobre la creación por código. Ahora bien, la asignación del sessionname, database que mencionas, ¿no estás hablando en serio al ponerlo como una desventaja, verdad? Usando un CreateQuery ¿evitas esa asignación? Quizá te refieres a que lo hace una sóla vez, pero ignoro porque habría de hacerlo varias veces usando un Query genérico en tiempo de diseño.
En resumen, si utlizas un diseño concurrente, es decir, donde un mismo proceso puede accederse varias veces simultáneas, pues desde luego que es necesario crear objetos en ejecución, pero va mucho más allá de un CreateQuery. Para otro tipo de aplicaciones, sigues sin convencerme. // Saludos |
#17
|
|||
|
|||
Yo opino exactamente sobre este tema como Roman, me alegro que haya sido él y no yo quien sostuviera este punto de vista, ya que así es más factible que se profundizara en el tema .
|
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Aplicacion carga muchas fichas en memoria. | zugazua2001 | Varios | 4 | 06-09-2005 17:40:41 |
cxGrid opcion dejar todo el resultado en memoria?? | sakuragi | OOP | 0 | 26-07-2005 16:38:27 |
Incluir DLL en Ejecutable | senpiterno | Varios | 1 | 24-01-2005 13:39:03 |
error al incluir bde en el uses | arc22 | Conexión con bases de datos | 1 | 28-06-2004 09:53:06 |
|