Cmo trabaja FoxPro internamente :: PortalFox :: Nada corre como un zorro

Pgina 1 de 10

Crec tu negocio online

Trabajs en programacin? Aument tu conocimiento de Google. Entr!
Google.com.ar/WebExpert

Hola invitado

29 Ago, 2011 - 04:52

Men principal

Inicio
Temas
Secciones
Descargas
Enlaces

Indice

Conferencias

MasFoxPro

Enviar noticia
Bsquedas
Usuarios
Preferencias
Top 10
P+F [FAQ]
RSS

Cmo trabaja FoxPro internamente

lecturas 10884

Enviado por LuisMaria en Jueves, 30 Noviembre, 2006

Artculo de Christof Wollenhaupt (Foxpert) traducido al espaol por Fernando D.

Bozzo, que nos da una visin del interior de Visual FoxPro.

Cmo trabaja FoxPro internamente

por Christof Wollenhaupt, Foxpert
Traducido por: Fernando D. Bozzo (fdbozzo@gmail.com)
Link original: http://www.foxpert.com/docs/howfoxproworks.en.htm

FoxPro desde adentro

Ads

Anuncios Google
FoxPro
Memoria
VFP Programmer
Matriz

Recomendar

Anuncios

rase una vez, que el xBase no era un lenguaje de programacin, era una herramienta para
recuperar y para manipular automticamente datos. Los usuarios de las herramientas xBase
no eran principalmente desarrolladores; eran expertos en una variedad enorme de diversas
reas que utilizaban FoxBase, dBase, y herramientas similares para manejar sus datos. El
xBase fue mejorado constantemente y finalmente desarrollado como un verdadero lenguaje
de programacin. FoxPro se convirti en un entorno profesional de desarrollo que alcanz sus
alturas con FoxPro 2.5/2.6. En 1995 el paradigma de la herramienta cambi otra vez. Un
lenguaje de programacin procedural se convirti en una herramienta orientada a objetos que
contina desarrollndose como un diseo basado en componentes.
Visual FoxPro no es slo un entorno orientado a objetos como Delphi o Visual Basic.NET.
Visual FoxPro todava contiene sus races. Slo intente hacer funcionar un programa de Turbo
PASCAL 3.0 en Delphi 7.0. Qu tal sus programas de GW-BASIC en Visual Basic.NET? Pero
Foxbase? Hasta hoy puede hacer funcionar cdigo sin cambios en Visual FoxPro que ha escrito
en los aos ochenta. La salida por pantalla no luce tan agradable, pero todava puede ejecutar
cdigo en VFP 8 casi 20 aos despus de que lo ha escrito.
Visual FoxPro es casi totalmente compatible hacia atrs. Pensando sobre esto, significa que
mucho del cdigo en FoxPro y FoxBase son todava parte de Visual FoxPro. Esto significa que
la orientacin a objetos se sienta encima de FoxPro, y no viceversa. Muchos comportamientos
extraos de Visual FoxPro llegan a ser solamente explicables si piensas cmo habras hecho
algo en FoxBase, slo para darse cuenta de que Visual FoxPro no lo hace distinto.
Una advertencia por adelantado: Los siguientes artculos intentan describir cmo trabaja
internamente Visual FoxPro. Los interiores reales de FoxPro son propiedad intelectual de
Microsoft y no se divulgan pblicamente. Cada uno de los que realmente saben como trabaja
FoxPro internamente esta impedido para hablar de esto firmando un Acuerdo de NoDivulgacin (NDA). He recogido la siguiente informacin de una variedad de fuentes pblicas.
Cierta informacin est en la biblioteca MSDN que Microsoft publica trimestralmente (algunos
items existen solamente en versiones ms viejas de la biblioteca MSDN). Otra informacin
viene del cdigo de ejemplo que Microsoft enva. La mayora de las piezas, sin embargo,
vienen de pruebas y de observaciones, no slo de m, sino de muchos, muchos
desarrolladores en varios foros. Especialmente las diferencias en el comportamiento de varias
versiones permiten hacer conclusiones de la estructura interna de VFP. Algunas de las
estructuras siguientes se han extendido en la versin ms reciente de FoxPro.

El ndice de la tabla de nombres (NTI)

http://www.portalfox.com/index.php?name=News&file=article&sid=2296&mode=nested... 29/08/2011

Cmo trabaja FoxPro internamente :: PortalFox :: Nada corre como un zorro

Traducir
espaol ingls
Traduccin
espaol-ingls en
1 clic. Descarga
gratuita!
www.Babylon.com

Bases de Datos
Compre listados de
individuos y
empresas con
perfiles
determinados
Marketing.Nosis.com

Sistema Tango
Gestion
Tango:Ventas,
Compras,
Contabilidad
Consulte
Promociones!. Te
4555-3000

Pgina 2 de 10

En Visual FoxPro podemos nombrar varios items. A esos items, Visual FoxPro les asigna algo
llamado un nombre. Estos items son variables (no propiedades), nombres de matrices,
procedimientos, funciones, alias de tablas, nombres de campo y objetos (no clases). Cada uno
de estos elementos tiene una etiqueta y un alcance. La visibilidad (alcance) de una variable,
por ejemplo, depende de su tipo, mientras que el alcance de un alias es la sesin de datos. Un
nombre de campo debe ser nico en una tabla y los procedimientos son limitados en alcance a
un archivo de programa.
Siempre que se crea una variable, se abre una tabla, y as sucesivamente, Visual FoxPro crea
una nueva entrada en una lista interna, la Tabla de Nombres. La posicin dentro de esta lista
es el ndice de la Tabla de Nombres - o NTI para abreviar. En esta lista, a cada nombre se el
asigna un nmero nico entre 1 y 65.000, porque se mantiene como valor de 16-bits. Hay
slo una lista global. Esta es la razn por la cul se pueden crear hasta 65.000 variables
solamente. Puesto que los alias y los nombres de objetos (hasta Visual FoxPro 6.0) tambin
se incluyen en esta lista, el nmero real de variables es reducido por el nmero de objetos
instanciados y reas de trabajo asignadas.
El manejo de esta lista se ha optimizado en las distintas versiones de FoxPro. Cuando se libera
un nombre cerrando una tabla o porque no se necesita ms una variable, Visual FoxPro no
quita la entrada inmediatamente. Solamente marca la entrada como invlida, como se hace
con los registros eliminados.
Los items finalmente son quitados por un proceso llamado Garbage Collection (recoleccin de
basura). Este trmino se refiere al proceso de quitar entradas invlidas de las listas, liberar
entradas desactualizadas de la cach, compactar la memoria moviendo bloques de memoria
alrededor, comprobando el acceso a los ficheros temporales, y as sucesivamente. Visual
FoxPro ejecuta la recoleccin de basura en su bucle ocioso (idle loop). Se entra en este bucle
siempre que Visual FoxPro est en una condicin de espera causada por READ, READ EVENTS,
INKEY() o WAIT WINDOW. Esto sigue siendo cierto si se utiliza el comando con las opciones
de no esperar (NOWAIT). Se puede utilizar este truco para forzar a Visual FoxPro a limpiar la
memoria usando un WAIT WINDOW "" NOWAIT.

www.Viconex.com

Gestion
Comercial Pyme
Software de
gestion
administrativa una
solucion para cada
empresa.www.mygestion.com.ar

2009 PortalFox

No fue hasta Visual FoxPro 7.0 que SYS(1104) se hizo en la documentacin an cuando la
funcin est disponible desde FoxPro 2.6, por lo menos. SYS(1104) dispara manualmente una
recoleccin de basura. No es lo mismo que el bucle ocioso, aunque, como en el bucle ocioso
Visual FoxPro hace ms que ejecutar la recoleccin de basura, como adicionalmente procesar
los mensajes de Windows. Durante la ejecucin del programa, Visual FoxPro no est en un
bucle ocioso y por lo tanto no realiza una recoleccin de basura. Hasta Visual FoxPro 5.0 esto
tena el efecto de que ms y ms entradas en la tabla de nombres han estado marcadas como
invlidas, pero no se liberaban.
Esto tena consecuencias de gran envergadura en la performance, pero tambin en la
estabilidad. Cada vez que una nueva entrada se agrega a la tabla de nombres, Visual FoxPro
tiene que buscar todas las entradas existentes para encontrar nombres conflictivos. Para las
variables esto implica comprobar si existe una nueva variable con un alcance ms bajo,
porque no se puede, por ejemplo, crear una variable PBLICA cuando existe una variable
LOCAL con el mismo nombre. Para los alias esto implica verificar que el nombre del alias no
est usado en la sesin actual de datos. Este proceso de bsqueda ha causado la degradacin
exponencial de la performance. Mientras que se podra medir la creacin del primer objeto en
milisegundos o incluso nanosegundos, a Visual FoxPro le tom varios minutos para crear el
objeto 60,000.
Las aplicaciones que nunca alcanzaban un estado ocioso, como las rutinas de importacin o
los proveedores de servicio, se hacan ms lentos cuanto ms tiempo funcionaban. Algunas
funciones, tambin, exigan una nueva entrada en la tabla de nombres, como la funcin
REQUERY al recargar una vista. La desaceleracin no era el nico problema. Cuanto ms se
acercaba una aplicacin al lmite, ms inestable se volva. Si se era afortunado, Visual FoxPro
indicaba un error de "demasiados nombres", pero generalmente simplemente se colgaba.
Visual FoxPro 6.0 mejor perceptiblemente este comportamiento. Cuando el nmero de items
en la tabla de nombres se acerca al 95% del lmite, Visual FoxPro inicia automticamente una
recoleccin de basura. En un programa que crea 65.000 objetos se nota como un descanso
ms largo al crear ese objeto.
Una mejora importante vino en Visual FoxPro 7.0. Todas las versiones anteriores contaron
objetos. Cuando se crean dos etiquetas

http://www.portalfox.com/index.php?name=News&file=article&sid=2296&mode=nested... 29/08/2011

Cmo trabaja FoxPro internamente :: PortalFox :: Nada corre como un zorro

Pgina 3 de 10

LOCAL loLabel1, loLabel2

loLabel1 = CreateObject("Label")
loLabel2 = CreateObject("Label")
Visual FoxPro ajusta la propiedad NAME. La primera etiqueta se nombra "Label1", para la
segunda etiqueta Label2.Name resulta en "Label2". Para hacer que esto suceda, Visual FoxPro
coloca cada objeto en la tabla de nombres. La consecuencia es que cada creacin de objeto
dura ms que la anterior. Se puede saltear esto hasta cierto grado asignando un nombre
nico como SYS(2015) en el evento Init. No obstante, este comportamiento limita el nmero
de los objetos que pueden ser instanciados a 65.000. En Visual FoxPro 3.0 a 6.0 no se pueden
crear ms de 65.000 objetos incluyendo todos los objetos que estn en formularios. Cuando
se ha alcanzado ese lmite, no se puede incluso abrir al diseador de formularios ya que
tambin intenta crear objetos.
Visual FoxPro 7.0 y 8.0 no hacen ninguna bsqueda de nombre nico cuando se crean objetos
con CREATEOBJECT () o NEWOBJECT (), ni colocan objetos en la tabla de nombres. Por lo
tanto se pueden crear lejos ms de 65.000 objetos e incluso ms rpidamente que en Visual
FoxPro 6.0 tambin. La desventaja es que los nombres de objetos no son mas nicos. Un
pequeo precio a pagar.

Variables, Matrices y Objetos

Una de las consultas ms frecuentes que hacen los desarrolladores que acaban de aprender
que Visual FoxPro puede manejar solamente hasta 65.000 variables es si eso se aplica a los
elementos de matrices tambin. La respuesta es un NO definitivo. Una matriz cuenta como
una sola variable, no importa cuntos elementos contenga. Porque el nmero de elementos se
limita a 65.000 tambin, se pueden crear 65.000 matrices con 65.000 elementos cada una,
como mximo. Incluso en Visual FoxPro se pueden almacenar masas de datos en memoria.
Debido a razones de performance, ninguna aplicacin se acerca a estos lmites siquiera. La
razn de todas estas limitaciones es la tabla de nombres, de nuevo. Realmente, Visual FoxPro
slo sabe tratar con variables -simples variables, eso es todo. El soporte de matrices, y
posteriormente objetos, ha sido acomodado en este diseo.
Pero qu es una variable en Visual FoxPro? Las variables en FoxPro pueden almacenar
valores de cualquier tipo de datos. Sin embargo, como Visual FoxPro est escrito en C en s
mismo, las variables de FoxPro tambin tienen que ser almacenadas en formato C hasta cierto
punto. Visual FoxPro almacena variables en estructuras de C. An cuando la estructura
siguiente proviene del kit de construccin de bibliotecas (SDK), est probablemente cerca de
qu utiliza internamente Visual FoxPro, si no es incluso idntico:
typedef struct {
charev_type;
charev_padding;
shortev_width;
unsignedev_length;
longev_long;
double ev_real;
CCY ev_currency;
MHandle ev_handle;
unsigned long ev_object;
} Value;
Adems del tipo, hay una entrada para cada tipo de dato soportado. Visual FoxPro utiliza
diversos campos dependiendo de qu tipo de datos deba ser almacenado. La estructura
explica porqu las cadenas pueden contener cualquier carcter (porque su longitud se
almacena por separado) y cmo Visual FoxPro se ocupa del nmero de posiciones decimales
en valores de coma flotante para permitir diferencias entre 1.0 y 1.00. Las cadenas y los
objetos reales no se almacenan directamente en esta estructura porque su tamao puede
variar ampliamente. Para acceder a cadenas, Visual FoxPro utiliza algo llamado menajador de
memoria que ser explicado en un momento. Los objetos se identifican usando un nmero de
32-bits no muy documentado. Puede ser que sorprenda que las matrices no estn siquiera
mencionadas.
Cada vez que un programa crea una nueva variable de memoria, Visual FoxPro asigna un
bloque de la memoria con la estructura antedicha. Su direccin tiene que ser almacenada en
alguna parte, justo como el nombre, que no es parte de la estructura anterior. Almacenar esta
informacin es el trabajo de la tabla de nombres. Cada entrada en la tabla de nombres

http://www.portalfox.com/index.php?name=News&file=article&sid=2296&mode=nested... 29/08/2011

Cmo trabaja FoxPro internamente :: PortalFox :: Nada corre como un zorro

Pgina 4 de 10

contiene adems de nombre y alcance, los detalles del tipo de la entrada (variable, campo,
alias, etc.) y su localizacin en memoria. La lista se limita a 65.000 entradas, por lo tanto, el
lmite mximo de variables.
Una matriz no se puede almacenar en una sola estructura, sin embargo. Cada elemento de
matriz se almacena en una estructura como una sola variable. sta es la nica manera de
poder almacenar los items de varios tipos de datos en una sola matriz. En la tabla de nombres
Visual FoxPro crea una sola entrada para la matriz entera. El siguiente ejemplo setea todos los
elementos en la matriz a NULL:
LOCAL laArray[3]
laArray = .NULL.
Esta sola entrada es la que es usada para pasar una matriz por referencia. La matriz real, por
otra parte, es una simple tabla de lista que contiene punteros a todos los elementos
individuales. La entrada de matrices en la tabla de nombres real contiene un puntero a esta
lista. No hay obviamente manera de tener acceso directamente a un elemento de la matriz
como se puede tener acceso a una variable. Al pasar el ndice de la tabla de nombres (NTI)
que Visual FoxPro utiliza para identificar unvocamente una entrada en la tabla de nombres a
una funcin que devuelva un elemento de la tabla de nombres, esta funcin podra solamente
devolver la entrada para la matriz entera. Otra funcin recibe esta entrada y devuelve un
elemento particular.
Los objetos se almacenan de manera similar. El valor en la estructura es la direccin de otra
tabla de nombres. Para cada objeto Visual FoxPro parece crear una nueva tabla de nombres.
Probablemente ha sido elegido ese camino porque la tabla de nombres ya maneja nombre y
alcance. Las propiedades en Visual FoxPro son realmente variables que se mantienen en un
lugar oculto. Ms asombrosamente, esto es as para los mtodos, que son tambin variables.
Por esta razn no se puede crear una clase que tenga ms de 65.000 mtodos, propiedades, y
eventos.
Este diseo tiene muchas ventajas ya que de otra manera las matrices y las propiedades
comeran rpidamente el espacio disponible de la tabla de nombres. La desventaja ms obvia,
sin embargo, es pasar parmetros por referencia usando el carcter @. En este caso, Visual
FoxPro no pasa una copia del valor como lo hace normalmente, sino simplemente el NTI, el
ndice de la tabla de nombres. A la funcin que llama se le pide amablemente que ponga el
resultado en la variable nmero x. Una matriz, sin embargo, tiene solamente un simple ndice
de la tabla de nombres. No hay posibilidad tampoco de especificar en qu elemento debe ser
escrito el resultado. Por lo tanto, se puede pasar solamente una matriz entera por referencia.
En Visual FoxPro es imposible pasar un solo elemento de matriz por referencia. Se tiene que
copiar el elemento en una variable, pasar una referencia a esa variable y actualizar el valor en
la matriz.
Igual se aplica a las propiedades de objetos. En teora, no se puede pasar una propiedad por
referencia porque es una parte integral del objeto. Pasar una propiedad por referencia, por lo
tanto, rompera la encapsulacin. La respuesta verdadera, sin embargo, es que una propiedad
no tiene una entrada dedicada en la tabla de nombres y pasarla por referencia es por lo tanto
imposible. Son afectadas especialmente por este diseo las propiedades matrices. Ni las
matrices ni las propiedades se pueden pasar por referencia. Por lo tanto no se tiene ninguna
otra posibilidad que copiar la matriz en una variable local, pasarla en lugar de la otra, y copiar
la matriz entera nuevamente usando ACOPY() para ambas maneras. Combinado con los
mtodos access y assign este mtodo tiene an ms desventajas que slo reducir la velocidad
de ejecucin. Afortunadamente, Visual FoxPro 8 agreg las colecciones que lucen como una
matriz, pero pueden ser fcilmente pasados alrededor.
El acceso a las variables ha sido optimizado por Visual FoxPro. Ya al compilar un programa
Visual FoxPro traduce nombres en valores enteros fciles de manejar. Las lneas:
LOCAL lcName, lcZIP
? lcName
Se convierten en el pseudo cdigo siguiente durante la compilacin:
LOCAL #1, #2
? #1

http://www.portalfox.com/index.php?name=News&file=article&sid=2296&mode=nested... 29/08/2011

Cmo trabaja FoxPro internamente :: PortalFox :: Nada corre como un zorro

Pgina 5 de 10

En el archivo FXP resultante todas las variables se enumeran al final del archivo. Dentro del
cdigo compilado, se utilizan valores de 16 bits que indican la posicin en la lista.
0x00000000
0x00000010
0x00000020
0x00000030
0x00000040
0x00000050
0x00000060
0x00000070
0x00000080
0x00000090
0x000000A0
0x000000B0
0x000000C0

:
:
:
:
:
:
:
:
:
:
:
:
:

FE
00
00
00
00
0B
01
4D
00
3A
65
00
00

F2
21
00
00
50
00
F7
45
00
5C
3A
29
00

FF
00
00
00
00
AE
00
05
00
74
5C
00
00

20
00
00
00
00
F7
00
00
00
65
74
00
00

02
00
00
00
00
00
FE
4C
00
6D
65
00
00

01
00
00
00
C2
00
03
43
00
70
6D
8F
00

00
00
00
00
8B
07
00
5A
00
5C
70
00
00

00
00
94
00
56
F7
55
49
00
00
5C
00
00

00
00
11
00
2B
01
02
50
00
76
76
00
00

B0
00
00
56
11
00
00
B1
00
61
61
00

00 00 00
00 00 00
00 00 00
00 00 00
00 00 00
FE 0A 00
06 00 4C
00 A1 00
00 00 00
72 2E 66
72 2E 70
00 00 00
.........

8F
00
25
03
FC
02
43
31
00
78
72
09

00
00
00
00
18
F8
4E
00
00
70
67
00

00
00
00
00
00
03
41
00
65
00
00
00

........ ..
.!..............
.......".....%..
.........V......
.P...V+......
...........
.....U....LCNA
ME..LCZIP..1..
...............e
:\temp\.var.fxp.
e:\temp\var.prg.
.)... ..........

Es reconocible inmediatamente que el cdigo real empieza en la posicin 0x50 y finaliza en

0x64. Lo siguiente lista el significado de la parte en negritas del archivo:
0B 00
AE
F7
00 00
07
F7
01 00
FE

length of first line (11 bytes)

code for the LOCAL statement
expression: a variable follows
variable #1 (lcName)
comma in list of parameters
another variable follows
variable #2 (lcZIP)
end of expression

0A 00
02 F8 03
01
F7
00 00
FE

length of second line (10 bytes)

code for the ? statement
number of parameters: 1
expression: a variable follows
Variable #1 (lcName)
end of expression

Al ejecutar tal programa, Visual FoxPro crea una lista que asigna cada variable en el cdigo al
ndice de la tabla de nombres. Internamente, FoxPro llama una funcin que recibe el ndice
como parmetro y devuelve una estructura completada conteniendo el valor. Como se puede
ver la longitud del nombre de la variable no es relevante. No se utiliza en el cdigo real del
programa, slo est enumerada una vez al final. Los nombres de variables ms largos (y a
menudo ms legibles) por lo tanto no tienen ningn efecto significativo en la velocidad de
ejecucin.
Una vez ms la situacin es diferente al observar las matrices. Las funciones internas para
determinar el NTI pueden todava ser utilizadas, pero Visual FoxPro no sabe hasta entonces
que esta variable es una matriz. En el paso siguiente los parmetros ndice se evalan y se
pasan a otra funcin que copie la estructura del valor para cargar un elemento de la matriz.
Acceder a un elemento de una matriz, por lo tanto, es siempre ms lento que acceder a una
variable. Para complicar ms las cosas, Visual FoxPro soporta corchetes y parntesis para las
matrices as como para funciones. No hay distincin clara entre los dos de antemano. Como
las matrices tienen precedencia, Visual FoxPro tiene que comprobar para saber si hay una
matriz del mismo nombre en cada llamada de funcin.
Es ms difcil para los accesos a los objetos. Una vez ms los nombres de propiedad se
convierten a nmeros usando el mismo algoritmo. Sin embargo, object1.name es casi igual
que object2.name. Si Visual FoxPro encuentra cdigo como este
LOCAL loLabel
loLabel = CREATEOBJECT("Label")
? loLabel.Caption
No es difcil resolver la referencia a loLabel en la tercera lnea. La funcin para obtener un
valor para la NTI devuelve una estructura que representa el objeto entero. El paso siguiente
es considerablemente ms complejo. Los objetos mantienen su propia tabla de nombres. La
lista disponible para convertir nombres en el NTI es intil. Por lo tanto, Visual FoxPro tiene
que localizar el nombre en el cdigo (CAPTION, en este ejemplo) en la tabla de nombres
privada y cargar la estructura all. Esto requiere la resolucin del nombre real en vez de usar

http://www.portalfox.com/index.php?name=News&file=article&sid=2296&mode=nested... 29/08/2011

Cmo trabaja FoxPro internamente :: PortalFox :: Nada corre como un zorro

Pgina 6 de 10

el valor de ndice y los resultados no se pueden poner en la cach como para los valores
simples. Por lo tanto, acceder a una propiedad de objeto es incluso ms lento que acceder a
una variable o un elemento de matriz.
Eso explica porqu WITHENDWITH puede aumentar la performance tan notablemente.
Simplemente mantiene la estructura de valores en memoria y hace innecesario resolver la
primera parte. Esto tambin explica porqu tiene mucho ms sentido guardar referencias
profundas en una variable local. Tal variable se puede resolver mucho ms rpidamente que
una propiedad.

Administracin de la memoria
Ni un bit menos complejo es el manejo de la memoria en Visual FoxPro. Ha habido dos
versiones de FoxPro 2.x, una versin de 16 bits y otra de 32 bits que utilizaban un extensor
del DOS. El extensor del DOS incluso cambi entre 2.0 y 2.6. Para las aplicaciones DOS hay
varios tipos de memoria, que son todos manejados por diversos administradores de memoria.
Estn XMS y EMS como modelos concurrentes de memoria. Est HIMEM el cul extenda la
memoria convencional y DPMI, el interfaz de modo protegido do DOS, que todava es
soportado por Windows. Todos estos tipos de memoria han sido soportados por varias
versiones de FoxPro; todava hay cdigo que permanece en Visual FoxPro, no obstante, no
activo. Por ejemplo, la mayor parte de las funciones indocumentadas de la memoria entre SYS
(1001) y SYS(1016) todava trabajan.
Windows agreg modelos de memoria ms modernos dependiendo de la versin de Windows.
Incluso en la versin actual de 32-bits de Windows hay varias clases de tipos de memoria
disponibles. Los tipos ms conocidos son la memoria fsica y la de intercambio (swap). La
memoria puede ser dividida an ms granularmente, como en montones locales y globales,
memoria virtual, memoria mapeada y muchos tipos ms.
Encima de la memoria fsica y de varios modelos de memoria implementados por el sistema
operativo, Visual FoxPro tiene su propia manejo de la memoria. Visual FoxPro distingue cinco
tipos de memoria: pila, memoria intermediaria fuera de la pantalla, grupo de manejadores y
ficheros temporales. El apilado se utiliza para los procesos temporales y no es relevante para
los desarrolladores de Visual FoxPro. Generalmente, se nota el apilado en condiciones de error
tales como "insufficient stack space" o "Mismatched PUSHJMP/POPJMP call". Solamente los
desarrolladores de C/C++ que escriben un FLL tienen que tratar con las pilas.
El grupo de manejadores (handle pool) es la administracin real de la memoria de Visual
FoxPro. Para hacer frente a todos los distintos mdulos de memoria, FoxPro implementa un
modelo inteligente que prohbe el acceso directo a la memoria. Debido a este modelo, FoxPro
puede ser portado hacia hacia otras plataformas que utilizan modelos de memoria
enteramente distintos, tales como Windows, Unix o el Mac.
Hay muchos datos para mantener en memoria. Esto incluye variables, menes, ventanas,
cadenas, pero tambin objetos, definiciones de clases, formularios, y mucho ms. Cada vez
que Visual FoxPro exige memoria, el administrador de memoria es llamado con el tamao del
bloque de memoria deseado. En vez de devolver una direccin, sin embargo, est devolviendo
una mananejador de memoria. Se puede imaginar esto como una clase de clave primaria.
Siempre que un programa desee tener acceso a esta memoria debe bloquearla antes, como se
bloquea un registro. Despus de eso se puede determinar la direccin usando una funcin
interna. Una vez accedida la memoria el cdigo tiene que desbloquear el manejador, como
desbloquear un registro.
El propsito de estos bloqueos es diferente al de los registros, sin embargo. El acceso paralelo
a la memoria es lo que debe ser prevenido, moviendo el bloque alrededor. Cuando los bloques
de la memoria son constantemente asignados, la memoria libre se fragmenta con el tiempo.
Lo mismo se aplica a los discos duros cuando se crean y eliminan archivos. Despus de
funcionar un largo tiempo esto podra conducir a la situacin de que hay bastante memoria
disponible, pero no hay ningn bloque que sea lo bastante grande como para almacenar los
datos solicitados. Esto sera fatal para un sistema de base de datos que debe funcionar
desatendido por das o semanas, ya que tal situacin colgara el sistema.
Para evitar que esto suceda, la recoleccin de basura debe mover bloques de memoria
alrededor. Internamente, Visual FoxPro realiza cierta clase de defragmentacin mientras que
est ocioso. Pero la defragmentacin no es la nica razn para implementar este modelo.

http://www.portalfox.com/index.php?name=News&file=article&sid=2296&mode=nested... 29/08/2011

Cmo trabaja FoxPro internamente :: PortalFox :: Nada corre como un zorro

Pgina 7 de 10

Adems, la memoria no est siempre fcilmente disponible. Por ejemplo, en DOS la memoria
axtendida debe ser mapeada a la memoria convencional antes que la versin extendida de
FoxPro pueda accederla. Cuando un manejador de FoxPro es bloqueado, las funciones de
administracin de FoxPro pueden tener el cuidado de asegurarse de que este bloque de
memoria est fcilmente disponible para el programa que llama. Cuando est desbloqueado,
FoxPro puede mover el bloque de nuevo a su posicin original.
Parte del grupo de manejadores es visible a nosotros los desarrolladores con el comando LIST
MEMORY, pero no todos los manejadores. Internamente Visual FoxPro hace uso intensivo de
manejadores tambin. Todas las ventanas de edicin, por ejemplo, son manejadores tambin.
Por lo tanto podemos utilizar ACTIVATE WINDOW no slo para activar nuestras propias
ventanas, sino todas las ventanas proporcionadas por FoxPro incluyendo las barras de
herramientas. En Visual FoxPro el grupo de manejadores es limitado solamente por la
memoria fsica y virtual disponible.
La funcin SYS(1001) devuelve el tamao mximo del grupo de manejadores. La funcin
indocumentada SYS(1011) devuelve el nmero de manejadores asignados. Esta funcin debe
devolver el mismo valor antes y despus de una llamada de funcin. Cualquier otro valor
indica un escape de memoria. SYS(1016) devuelve el tamao de la parte asignada del grupo
de manejadores. SYS(1104) inicia manualmente una recoleccin de basura. Esta funcin est
documentada oficialmente desde Visual FoxPro 7.0. Todas estas funciones devuelven varios
valores cuando son ejecutadas en la ventana de comandos, porque la ventana de comandos
entra permanentemente en el bucle ocioso y por lo tanto ejecuta una recoleccin de basura.
Algunas funciones se filtran en los manejadores usados internamente, otras no hacen eso. No
obstante, estas funciones son buenos indicadores para el uso de la memoria.
Bsicamente, todo lo que no es temporal se almacena en el grupo de manejadores en alguna
parte. Esto incluye transacciones y los cambios sin comprometer en un buffer intermedio que
deben ser escritos nuevamente con TABLEUPDATE().
El grupo de pginas (page pool) es el rea de la memoria que es controlada por SYS(3050).
Visual FoxPro guarda en ella mapas de bits creados por Rushmore y la utiliza para guardar en
cach las tablas y los ndices. Esta parte de la memoria es principalmente responsable de la
impresionante velocidad de Visual FoxPro. Todo lo que se lee en disco se cacheado aqu para
una reutilizacin posterior. Se puede controlar el tamao mximo de esta rea de memoria
por separado para el primer plano (foreground) y para el proceso de fondo (background). Eso
significa que dependiendo de si el usuario est trabajando con su aplicacin, o no, usted
puede decirle a Visual FoxPro que utilice menos o ms memoria. Esa memoria no es asignada
inmediatamente, sino que se asigna segn lo necesitado. Se puede especificar un valor
enorme sin tener que temer que esta cantidad de memoria se vaya inmediatamente.
SYS(3050) intenta asignar memoria en Windows que no se intercambie al disco. Sin embargo,
no hay garanta. Los qu podra sucederle es que Visual FoxPro haya asignado la memoria
para propsitos de cach que existe solamente en el disco duro local como memoria virtual.
Obviamente, esto tiene un impacto absoluto en la performance. Reduciendo el valor de SYS
(3050) inmediatamente libera toda la memoria superflua. Como el valor mnimo es 256 KB
(no MB), se puede utilizar el cdigo siguiente para liberar memoria ms all de 256 KB:
lcMemory = Sys(3050,1)
Sys(3050,1,1)
Sys(3050,1,Val(lcMemory))
An cuando es verdad que se tiene control completo sobre el grupo de pginas, sta es
solamente la mitad de la verdad en cuanto a la consumicin de memoria concierne. Si Visual
FoxPro es de la opinin que necesita ms memoria, por ejemplo, para almacenar un mapa de
bits de la optimizacin, entonces no vacila en crear ficheros temporales si el grupo de pginas
no es suficientemente grande. FoxPro contina funcionando, aunque el valor de SYS(3050)
sea demasiado bajo, eventualmente con la misma velocidad, quiz ms lento, o an ms
rpidamente. Esto depende de qu clase de memoria se asigne a Visual FoxPro y qu
dispositivo sea ms rpido. Es el que est usado por Windows para la memoria virtual o el
que es utilizado por Visual FoxPro para almacenar ficheros temporales? Como Windows,
tambin puede almacenar en cach el acceso a los archivos TMP, puede ser que note
repentinamente que su aplicacin funciona ms rpidamente.
Qu directorio se utiliza para los ficheros temporales depende de los ajustes del registro, el
TMPFILES= que elija (no TEMPFILES!) y varios ajustes en Windows. Bajo circunstancias

http://www.portalfox.com/index.php?name=News&file=article&sid=2296&mode=nested... 29/08/2011

Cmo trabaja FoxPro internamente :: PortalFox :: Nada corre como un zorro

Pgina 8 de 10

normales puedes utilizar SYS(2023) para descubrir el directorio temporal. A veces, sin
embargo, Visual FoxPro puede silenciosamente cambiar a un directorio distinto. Esto puede
ser causado por un nmero de factores. En todo caso, se debera observar la salida del seteo
SYS(2023) actual ya que puede ser que difiera del directorio temporal normal usado por
Windows. El peor caso es que Visual FoxPro utilice el directorio raz del usuario o el directorio
del programa, ambos a menudo que estn en el servidor. Realmente para estar seguro donde
van los ficheros temporales, se podra crear un cursor y determinar su posicin con la funcin
de DBF(). An cuando un cursor se crea generalmente en el mismo directorio donde apunta
SYS(2023), este no son siempre es el caso.

Rushmore
Rushmore es ms que una tecnologa, es un mito. Esto no debe pararnos, sin embargo, de
figurarnos que hay detrs de ese mito. Especialmente con este asunto es importante distinguir
los hechos de la ficcin. En la ltima dcada la regla era crear un ndice por DELETED(), justo
lo contrario es verdad en esta dcada. Ninguna de ambas, sin embargo, son realmente la
verdad.
La razn del funcionamiento de Visual FoxPro tiene dos fundamentos. Un fundamento es
Rushmore, el otro fundamento es el uso verdaderamente agresivo de la cach. La diferencia
del funcionamiento de otras bases de datos con algoritmos de bsqueda centrados en mapas
de bits (pues Rushmore es uno) no es causada sobre todo por Rushmore, sino debido a su
estrategia de cach y a un acceso de red optimizado.
Rushmore es un algoritmo orientado a mapas de bits. Visual FoxPro crea una lista para cada
condicin que se pueda optimizar con Rushmore. Esta lista determina si un registro satisface
los criterios de bsqueda o no. Visual FoxPro utiliza un solo bit para cada registro, pues hay
solamente dos estados posibles para cada registro. Ocho registros caben en un byte. Si se
tiene una tabla de 8-millones-de-registros, cada condicin de la bsqueda toma 1 MB de la
memoria.
Cada bit comienza siendo 0 - no seteado - y el registro correspondiente est por lo tanto en el
conjunto de resultados. Una vez que los mapas de bits hayan sido determinados para todas
las condiciones, esos mapas de bits se combinan bit-a-bit. Si se utiliza la condicin siguiente
en una consulta:
NAME = "Smith" AND InvoiceDate < DATE()-60
Esta consulta resulta en la creacin de dos mapas de bits independientes que contienen todos
los registros para "Smith" y todos los registros con una fecha de factura menor a 60 das. En
cada mapa no importa si la otra condicin no se satisface. Despus de eso ambos mapas de
bits son combinadas bit-a-bit con AND. El resultado es un mapa de bits que tiene solamente
un bit seteado para aquellos registros que satisfagan ambas condiciones. No es difcil
imaginarse que el uso de la memoria para acumular estos mapas de bits puede rpidamente
crecer y retrasar una consulta. Si tienes solamente una sola condicin, puedes utilizar el viejo
estilo del dBase:
SET ORDER TO RequiredIndex
SEEK Value
SCAN WHILE Field=Values
* do something
ENDSCAN
En muchos casos esto es incluso ms rpido que una consulta optimizada con Rushmore
porque Visual FoxPro no tiene que crear un mapa de bits. Por otra parte, esta tcnica no
utiliza la cach de la misma forma que Rushmore, haciendo consultas repetidas a los mismos
datos ms rpidas en Rushmore. Rushmore trabaja como el bucle SCAN anterior seteando el
bit dentro del bucle.
Cmo se crea realmente este mapa de bits? El factor ms importante es que el ndice en
Visual FoxPro est almacenado como b-tree, un rbol equilibrado. Cada nodo es un bloque de
512 bytes que puede contener hasta 100 punteros para subordinar nodos. Los nodos cerca de
la raz referencian a los valores clave, slo los nodos de la hoja referencian a registros. Como
cada nodo no referencia solamente a otros dos bloques, como se podra haber supuesto, la
jerarqua en el archivo del ndice puede seguir siendo generalmente muy plana. Adems,

http://www.portalfox.com/index.php?name=News&file=article&sid=2296&mode=nested... 29/08/2011

Cmo trabaja FoxPro internamente :: PortalFox :: Nada corre como un zorro

Pgina 9 de 10

todos los nodos se ligan horizontalmente.

Cuando Visual FoxPro busca un valor, navega a travs del rbol verticalmente de arriba hacia
abajo hasta que encuentra el registro. Entonces contina leyendo horizontalmente mientras el
valor de la bsqueda coincida con el que est en el ndice. Esta estrategia de lectura abajo y
de lado reduce el nmero de los nodos del ndice que tiene que leer, pero incrementa el
nmero de nodos al actualizar el ndice. Mientras que lee horizontalmente, Visual FoxPro setea
el bit correspondiente para cada registro encontrado. Esto es posible porque la entrada de
ndice contiene el nmero de registro as como el valor clave. Los datos se almacenan
comprimidos sin embargo. As es cmo el operador igual trabaja.
Otras operaciones trabajan de manera similar. Por ejemplo, si se desean encontrar los
registros que no son iguales, Visual FoxPro comienza con un mapa de bits en el cul se setean
todos los registros. Entonces realiza la misma bsqueda que cuando busca los registros
iguales, salvo que limpia bits cuando encuentra un registro. Al buscar por menor o mayor que,
simplemente se mantiene leyendo la lista hacia la derecha o hacia la izquierda hasta que
FoxPro alcanza el final del archivo.
Con Rushmore Visual FoxPro puede determinar qu registros no estn en el conjunto de
resultados, no los registros que estn en el conjunto de resultados. se es el porqu la fase de
Rushmore es seguida por la fase post-exploracin. Cada registro que ha sido determinado por
Rushmore se lee totalmente desde disco. Sin una expresin optimizada stos son todos los
registros en todas las tablas. Cada uno de estos registros entonces se comprueba para las
expresiones inoptimizables restantes. Adems, todas las expresiones optimizables se evalan
de nuevo, ya que algn otro pudo haber cambiado el registro mientras que Visual FoxPro
creaba el mapa. Por lo tanto el conjunto de resultados podra no contener todos los registros
que coinciden actualmente con los criterios de bsqueda, pero nunca se obtienen registros
que no coinciden con los criterios de bsqueda.
Hay una excepcin a esta regla, sin embargo. Al contar registros, Visual FoxPro intenta evitar
la fase post-exploracin. Cuando se ha construido el mapa de bits y no se deja ninguna
expresin inoptimizable, Visual FoxPro comienza a contar los bits seteados. Por lo tanto
COUNT FOR y SELECT CNT(*) FROM son extremadamente rpidos si una consulta se optimiza
completamente. Una optimizacin parcial no es suficiente. Tampoco ayuda utilizar ningn otro
mtodo de cuenta como SELECT SUM(1) FROM...
Cuando se crea el mapa de bits Visual FoxPro tiene que leer todos los bloques de ndice que
coinciden con los criterios de bsqueda. Las accesos repetidos hacen que Visual FoxPro
recupere estos bloques de la cach. Sin embargo, se desecha la cach si una estacin de
trabajo cambia un campo puesto en un ndice o agrega un nuevo registro. Visual FoxPro
puede determinar slamente que otra estacin de trabajo ha cambiado el ndice, pero no qu
ha cambiado exactamente. Por lo tanto la cach entera se desecha. Se puede explotar esto
para medir la performance. Usando una segunda instancia de FoxPro que reemplace un campo
del ndice en el primer registro en un bucle.
Hace algn tiempo la gente comenz a darse cuenta de que un ndice por DELETED() no es
siempre la solucin ptima. Parece que hay una clase de contra-movimiento que condena
totalmente el ndice, que tampoco es una buena idea. Cundo Rushmore es una buena idea es
realmente muy fcil de determinar. Si se leen ms bytes en el archivo del ndice que los
registros que se quitan durante la post-exploracin, Rushmore disminuye la performance. Se
tienen que comparar los bytes que se transfieren realmente.
Por lo tanto se necesita tener presente que la cach tiene un impacto con Rushmore y que los
ndices CDX estn almacenados comprimidos. Los comienzos iguales de una palabra se
almacenan solamente una vez. La cantidad real de datos se puede determinar con el monitor
del sistema en Windows. An los resultados ms exactos son posibles con un monitor de red
como NETMON.EXE que viene con Windows 2000 server, o Ethereal que est disponible
gratuitamente en http://www.ethereal.com. Tal monitor de red revela qu parte de un
archivo se lee realmente. Combinado con la estructura de los archivos del archivo de ayuda se
pueden determinar muchos detalles.
Si una aplicacin cambia montones de datos estos invalidan con ms frecuencia la cach. Por
lo tanto, tal aplicacin se beneficia menos de Rushmore que, por ejemplo, una aplicacin de
catlogo de CD's que ha puesto todos los datos en la cach despus de un corto tiempo de
usarla.

http://www.portalfox.com/index.php?name=News&file=article&sid=2296&mode=nested... 29/08/2011

Cmo trabaja FoxPro internamente :: PortalFox :: Nada corre como un zorro

Pgina 10 de 10

Si su aplicacin tiene muchos registros eliminados tambin se beneficia de Rushmore. Si su

aplicacin visita un registro mltiples veces porque, por ejemplo, el algoritmo requiere la
navegacin por los registros siguientes y anteriores, Rushmore es superior pues puede
reutilizar los mapas de bits mientras que el cdigo del viejo estilo del xBase tiene que releer
todos los registros repetidamente.
Si se desea determinar el nmero de hits antes de que realmente se ejecute la consulta dando
a sus usuarios la chance de evitar consultas duraderas, su consulta debe ser completamente
optimizable. Esto le da una ventaja verdadera de velocidad ya que crear un mapa de bits
toma significativamente menos tiempo que leer la tabla entera, y el mapa de bits puede
incluso ser reutilizado si el usuario decide ejecutar la consulta.
Otro factor importante es la distribucin de valores en el campo indexado. Hay una diferencia
enorme si se busca un valor nico como una clave primaria o un campo de estado que pueda
tomar solamente diez valores distintos. Un ejemplo extremo es el ndice por DELETED() para
el cual todos los campos tienen generalmente el mismo valor. En general se deben evitar tales
ndices a menos que los necesite para propsitos de contar.

Palabras Finales
Este documento puede dar solamente una breve introduccin sobre el funcionamiento de
Visual FoxPro. Muchas cosas slo las he mencionado brevemente. Algunas cosas incluso no
pudieron tener sentido cuando usted las ley la primera vez. Se mantiene la pregunta: Se
necesitan conocer todas estas cosas? Ciertamente, no. Pero saber algunas de estas cosas le
puede ayudar a evaluar riesgos de forma ms precisa. Podra explicar porqu ocurren ciertos
errores que parecen ser al azar. Y es slo y simplemente interesante saber qu se est
ocurriendo por dentro.

Cmo trabaja FoxPro internamente | Entrar/Crear una cuenta | 0 Comentarios

Mostrar Anidado

Orden Los ms viejos primero

Refrescar

Los comentarios son propiedad de sus respectivos autores.

No somos responsables de su contenido.

Todas las marcas y los logos utilizados en este sitio son propiedad de sus respectivos dueos.
Los artculos, noticias y comentarios son propiedad y responsabilidad de sus respectivos autores.
Copyright 2000-2010 PortalFox. Todos los derechos reservados.

http://www.portalfox.com/index.php?name=News&file=article&sid=2296&mode=nested... 29/08/2011