Rendimiento

Casi nada... un tratado sobre .Net en un mensaje... voy a intentarlo, lee...

string y StringBuilder

Siempre que hagas concatenaciones usa StringBuilder. Si sabes el tamaño de
la cadena a priori, aunque sea aproximadamente, diselo en el constructor.
Las cadenas en .NET son imutables si cambian se copian a una nueva posición
de memoria y eso tiene el coste de asignar esa memoria.

Reflection

Siempre tiene un coste muy alto, el truco: Utiliza interfaces, crea el
objeto por reflection, haz un cast a una interface que defina las funciones
que implementa el objeto y que quieres llamar, asi solo pagas el coste de
Reflection una vez. Esto sirve en muchos casos, como el tema de plugins y
demás, en los que se usa remoting.

Uso de Hilos. Threading. Cuántos hilos como máximo (aprox)
pueden crearse en WinForms?

No hay limite, más alla de la capacidad del sistema, pero ojo con los hilos,
muchos degradan el rendimiento por que exigen memoria y tiempo de procesado
que solo se gasta en planificarlos y en cambios de contexto. El truco: No
crees hilos!!!!!! Usa invocación asincrona y el pool de hilos para el 99% de
las veces sirve.

Aqui tienes una recopilación de articulos sobre el tema:

.NET: Practical Multithreading for Client Apps -- MSDN Magazine, January
2004
http://msdn.microsoft.com/msdnmag/issues/04/01/NET

Windows Forms: Give Your .NET-based Application a Fast and Responsive UI
with Multiple Threads -- MSDN Magazine, February 2003
http://msdn.microsoft.com/msdnmag/i...ithreading

.NET Delegates: Making Asynchronous Method Calls in the .NET Environment --
MSDN Magazine, August 2001
http://msdn.microsoft.com/msdnmag/i...1/08/async

Basic Instincts: Asynchronous Method Execution Using Delegates -- MSDN
Magazine, January 2004
http://msdn.microsoft.com/msdnmag/i...cinstincts

Basic Instincts: Updating the UI from a Secondary Thread -- MSDN Magazine,
May 2004
http://msdn.microsoft.com/msdnmag/i...cInstincts

En ASP.NET se pueden crear
hilos sin incidencia en el rendimiento ?, es decir, miles
de usuarios "atacando" al IIS 6.0,...y si usamos hilos,
qué pasaría ?.

Casi nunca en asp.net aportan nada los hilos. Ten en cuenta que el propio
IIS y Asp.net manejar un pool de hilos para manejar cada una de las
peticiones que recibien. Lo vas a hacer tu mejor que los ingenieros de MS?
Aun asi hay contados casos en los que los hilos pueden servir, pero ojo
pueden dañar la escalabilidad de tu aplicación salvo que no sepas muy bien
lo que haces. Ante la duda no los uses.

Dónde está recomendado y dónde
contraindicado eluso dehilos para winforms y asp.net ?.

Si puedes evitarlo no uses hilos, es la ultima opción. Salvo que el sistema
sea multiprocesador no ganas velocidad, solo velocidad percivida, una tarea
tarda menos en completarse si no hay hilos de pormedio, eso si sirven para
evitar que la interfaz de usuario se bloquee. Recuerda llamadas asincronas y
pool de hilos. Otro tema es que los hilos hay que sincronizarlos y no es
facil salvo que se tenga experiencia. Como andes con hilos te acabas
enredando, no falla. Por ultimo: NUNCA ACTUALICES UN CONTROL DESDE UN HILO
QUE NO SEA EL QUE LO CREO, en apariencia no pasa nada pero los errores
apareceran cuando menos esperes. Usa el metod Invoke del control, pero eso
tambien tiene un precio que se paga en rendimento.

Lee: Updating the UI from a Secondary Thread
http://msdn.microsoft.com/msdnmag/i...fault.aspx

Problemática de Acceso a datos. Dataset vs Datareader, y
como no, una consulta (por las razones que sean, aunque se
hagan filtros) devuelve miles de registros. Qué opciones
hay para mejorar el rendimiento ?, si obtenemos un Dataset
con miles de registros será inviable, aunque luego hagas
paginación, no?, Dataset si haces un Select te devuelve
todas las filas, o sea, las miles.
Qué diferencias habría en este caso entre WinForms y
ASP.NET ?.

Performance Comparison: Data Access Techniques
http://msdn.microsoft.com/library/d...ppArch.asp

Mantener Conexión única para toda la aplicación, tanto
WinForms, o ASP.NET, daría muchos problemas ?.

Ni se te ocurra. La contención acabaria con el rendimiento de tu aplicación,
una operacion esperando que acabe la anterior... mala idea. Coje tarde la
conexión, devuelvela pronto, asi exprimiras al maximo el pool de conexiones
de ado y el rencimiento de tu aplicación te lo agradecera. Usa la misma
cadena de conexión siempre que puedas, evitaras la creación de varios pools.

System.IO. Acceso a ficheros grandes de muchísimos MB,
busqueda en contenido de los ficheros. Aquí supongo
influencia de MemoryStream, FileStream.

.NET usa los I/O completion ports, todas la operaciones con streams son
bastante optimas.

Web Services. No he visto sobre ellos, pero supongo que
una gran cantidad de datos a enviar por WS sería inviable.

Bastante inviable. Pero nunca debes mover muchos datos por la red, menos si
internet es parte del canal y menos si estos datos estan adornados por
XML...

Serialización. Cómo afecta al rendimiento, tanto Binary,
XML, SOAP.

http://msdn.microsoft.com/library/d...arch14.asp

En fin, de momento se me ocurre eso en cuestión de
rendimiento.

Quizá sea un tema muy amplio,pero me gustaría que
aportaran su conocimiento o me remitan a referencias
buenas.

Amplio dices... no tiene fin...

Esto es todo amigos


Un saludo
Rodrigo Corral González [MVP]

FAQ de microsoft.public.es.vc++
http://rcorral.mvps.org