|
Buffering – Memoria temporalAlgunas veces es necesario procesar datos con cierta velocidad o cantidad conocida, la lectura de datos de 1 en 1 puede producir que en un cierto momento nuestro programa se quede sin hacer nada, o simplemente es más efectivo leer un archivo por bloques de datos grandes que de byte en byte (sobrecarga de llamadas a la misma función). En otras ocasiones podemos estar recibiendo datos por la red y si nuestro programa es lento para procesarlos o necesita atención por parte de un usuario para decidir que hacer, puede suceder que lleguen más datos de los que se pueden procesar, en este caso podemos utilizar un segmento de memoria temporal para almacenar estos datos y que no se pierdan y así aprovechar el tiempo en el que no llegan datos. El criterio para implementar estos tipos de memorias temporales (buffers de aquí en adelante) es variable, siempre se tomará en cuenta el promedio de datos que lleguen a nuestro programa o la cantidad de veces que es necesario llamar a una función que lee datos si lo hacemos con bloques más pequeños o más grandes, el valor óptimo siempre es empírico. Para determinar este valor siempre tendremos en cuenta que bloques más grandes de datos consumen más memoria del sistema operativo, y que muchas veces para mover bloques grandes de datos se puede perder mucho tiempo, por otra parte si nuestro archivo del disco no dispone de datos para llenar esos bloques, estaríamos desperdiciando memoria si abriéramos muchos archivos más pequeños que el buffer, por otro lado si el buffer es muy pequeño, entonces el efecto es contrario, estaríamos llamando innumerables cantidades de veces a la función leer, por lo que produciríamos un desperdicio de recursos del procesador, enlenteceríamos el sistema operativo, entonces queda claro que no leeremos archivos en bloques de 1MB ni lo haremos byte por byte. Usando arreglos para un buffer, colas de espera, pilas y listas.Bien, pongamos el siguiente ejemplo, se quieren enviar datos de una máquina a otra en un sólo sentido, una telefonista debe llamar a ciertos teléfonos que llegan desde otro punto de una red y no puede ver el siguiente teléfono hasta que haya terminado su llamada, del otro lado una secretaria que revisa el correo con una frecuencia de 5 minutos envía los teléfonos del soporte técnico que deben ser atendidos por la telefonista, teniendo en cuenta que las llamadas suelen durar entre 10 a 30 minutos y que los correos que pueden llegar al mismo tiempo no son más de 6 y que existen lapsos de hasta 60 minutos sin recibir ni un sólo correo, y que no quedan llamadas pendientes en el transcurso del día. Criterios:
Los últimos tres criterios son suposiciones, que en la vida real son la telefonista y secretaria quienes pueden proveer este tipo de estadística sobre los horarios más saturados, tenemos que tener en cuenta que el problema es humanamente soluble ya que no quedan pendientes sin tratar así que durante el día se resuelven todos los llamados: 20min x 4p = 80min => 1) se resuelven en 80 minutos 2 llamados y ¾ 2) se acumularon casi 40 tel – 3 tel = 37 tel Entonces en el peor de los casos la acumulación máxima probable y el despacho de teléfonos más tardado producen un máximo de 37 teléfonos. Entonces nuestro buffer óptimo es de 37 elementos. Como almacenar un teléfono no consume tanta cantidad de recursos de un sistema utilizaremos un buffer de 40 elementos. Nota: el manejo de memoria RAM en el sistema para valores o tipos de datos de almacenamiento fijo, como son todos los tipos de datos básicos excluyendo “String”, es de potencias de 2n y a veces de múltiplos de estas potencias, siendo recomendable elegir siempre un valor cercano pero no igual porque si la JVM utiliza bloques de 64enteros como buffer interno si usáramos 65enteros estaríamos obligando a usar el espacio de 128enteros. leavecomment |
|
|||||||||||||||||||||||
*Hasta que esta leyenda no desaparezca el libro no ha sido terminado, descarge en pdf:
http://compunauta.com/forums/linux/programacion/java/ebook.html
