Cita:
Empezado por AgustinOrtu
Embarcadero tiene dos problemas que impiden convertir los compiladores para Win32 y Win64 en compiladores ARC: el codigo existente que puede perder compatibilidad hacia atras; y problemas de performance. Performance sobre todo para servidores, en donde desde luego un manejo de la memoria "personalizado" seguro que es superior a uno "automático";
|
Lo del performance es falso. Es todo al revez.
Un recolector de basura es más eficiente para servidores que el reference counting o el manejo manual.
El problema de los GC es que (tal vez, depende del tipo que se use) introducen pausas y que consumen más memoria. Por eso, el modelo de ARC es ideal para móviles: No introduce pausas (que sería más notable en un equipo que casi en su totalidad funciona como interface de usuario) y consume menos memoria (que se traduce en mayor longevidad en la batería y economía de recursos).
Pero los GC son más eficientes en un entorno de servidor porque pueden operar en "batch" sobre un mayor rango de memoria (
por ejemplo, sobre .NET), e incluso puede delegarse a un hilo aparte.
Esto conduce a la idea contra-intuitiva que Java arrasa en desempeño a otros entornos (osea, en workloads de servidor), porque tiene uno de los VM/GC mejor tuneados de la industria.
Esto es GC 101:
http://www.iecc.com/gclist/GC-faq.ht...on%20questions
http://www.memorymanagement.org/
----
Tengan en cuenta que un VM/GC vs manual es similar a un lenguaje alto nivel vs. assembler:
Asi como es posible que un humano escriba el mejor assembler posible, pero esto seria un humano MUY ESCASO y que en la realidad la *mayoria* seran derrotados por el assembler de un compilador decente <- porque este compilador decente a sido escrito por *ese tipo de humanos escasos*.
Entonces, un GC/VM derrota al promedio de los humanos a la hora de manejar la memoria. Mientras es posible escribir un código superior, hacerlo todo el tiempo correctamente es MUY dificil y escaso.
Ademas, aunque Delphi es mas de alto nivel que C/C++ sin perder su capacidad de ser eficiente tiene el problema de que carece de un protocolo/idioma universal como el RIIA, dejando en manos del programador promedio todo el proceso.