String.Empty o ""

Si te refieres a C++ la asignación de memoria en aplicaciones Windows no
es tan transparente como pueda parecer. Windows solo permite reservar
memoria en bloques de 4K (bueno, permite reservar bloques de *cualquier*
tamaño, pero lo alineará a 4K). Por eso, todos los runtimes de los
compiladores traen su propio gestor de asignación (como hace el .NET),
pero ese gestor es un poco *tonto*. Ahora no sé cómo será, en la época del
Borland C++ (3, 4 y 5, ojo, no C++Builder, sino Borland C++) el gestor que
traía Borland era una lista enlazada. Cuando tu pedías un bloque de
memoria mediante malloc o new, el runtime recorría esa lista enlazada para
encontrar el mejor hueco posible, y si no lo había, pedía a Windows un
nuevo bloque de memoria y lo añadía a su lista. Todo eso requiere tiempo
de ejecución y más gastos de memoria, ya que cada asignación nueva era un
bloque más en la lista enlazada, con cambios de punteros, etc. Como C++
trabaja con direccioens reales, esa lista no se podía compactar ni mover
ni hacer nada con ella excepto rezar que el programador supiera pedir y
liberar memoria de forma correcta. Aunque el MMV de Windows pueda mover
esos bloques y compactarlos por debajo, la fragmentación y los huecos
siguen quedando.

Si un programa asigna 1000 bloques de 1k, los libera uno sí y otro no, y
luego asigna otros 1000 bloques de 2K, el cosumo real de memoria son los
1000 bloques anteriores y los 1000 nuevos, ya que ninguno de los nuevos
cabe en los 500 liberados.

El compilador y el runtime no pueden hacer nada: en C++ los bloques de
memoria no se pueden mover ni compactar así como así. Y de hecho tu puedes
sustituir el asignador de memoria por defecto, o sobrecargar new para unas
clases y usar otro asignador. Por eso Windows tiene tantas funciones de
trabajo con memoria, heap local, heap global, creación/destrucción de
heaps, asignaciones en el espacio virtual o el real, acceso a memoria
mediante handles en lugar de punteros, memoria como ficheros, ficheros
como memoria, memoria compartida, hasta el Visual C++ trae una cosa
llamada punteros relativos o "based" (algo así como los punteros
interiores de C++/CLI)...

En .NET la cosa funciona mucho mejor, ya que hay un gestor de memoria (no
sé si bueno o malo, mejorable o inmejorable), pero que si se le deja
actuar hace su trabajo, manteniendo tres generaciones de objetos,
moviéndolos y compactándolos de la mejor forma posible. Y cuando haces una
asignación de memoria la tienes de forma inmediatísima ya que es el primer
bloque disponible, la única sobrecarga sería todo el envoltorio de
llamadas .NET al API nativo. Pero si en .NET empiezas a asignar y liberar
memoria de forma rápida y sin dejar actuar al recolector, entonces estás
en peor caso que C++, ya que añades la compilación al vuelo más el tiempo
de recorrer prácticamente las mismas estructuras de datos que en C++.

Realmente no sé cómo estan hechos en la actualidad los asignadores de
memoria, pero dada la cantidad de memoria disponible, yo los haría con
árboles-B con subida de nodos según la frecuencia de acceso (no recuerdo
su nombre real), cambiando algo más de consumo de memoria interna por
velocidad, tanto el asignador de C++ como el del .NET.



On Tue, 22 Jul 2008 15:11:33 +0200, Carlos wrote:

Pero, el compilador no deberia ser mas habil y convertir todo a una
misma forma standard ? o lo hace?

"RFOG" wrote in message news:

On Tue, 22 Jul 2008 13:02:37 +0200, Hernan wrote:

Es verdad que "" crea un objeto, pero la diferencia es mínima (la
velocidad
de creación de objetos de la máquina virtual de .NET es comparable a
C o C++). Encontrarás mas diferencia si usas string.Equals en vez de

A veces, cuando has fragmentado mucho la memoria en C++ (por ejemplo,
creando y destruyendo pequeños objetos sin mucho concierto, casi lo
habitual si no te andas con ojo), la asignación de memoria en .NET es
bastante más rápida que en C++ si dejas tiempo al recolector de basura
a que haga su trabajo en los tiempos muertos.

=>>> por lo que la comparación sería:
xxx.Equals(string.Empty)

Pero como han dicho antes lo mas performante es comparar por longitud
0.
Es lo que recomienda Microsoft y es lo que informa FxCop cuando
analiza
tu código.

En mi opinión, en estas situaciones lo mejor es acostumbrarse a
utilizar
unas pocas "construcciones idiomáticas" que sean fáciles de entender
para cualquiera que lea el código (la hora del programador es mas
costosa
que la de la CPU). En este caso particular uso solo dos:

variable == "" o variable.Length == 0

dependiendo de las ganas de micro-optimizar que tenga.

-Hernán.

==>> Mi blog sobre programación: http://geeks.ms/blogs/rfog
Momentos Leves: http://momentosleves.blogspot.com/
Cosas mías: http://rfog.blogsome.com/
Libros, ciencia ficción y programación
>> El poder de moverse a sí mismo es la esencia del alma.

Microsoft Visual C++ MVP
==Mi blog sobre programación: http://geeks.ms/blogs/rfog
Momentos Leves: http://momentosleves.blogspot.com/
Cosas mías: http://rfog.blogsome.com/
Libros, ciencia ficción y programación
El poder de moverse a sí mismo es la esencia del alma.