To process procedures, the executable procedure code must be in the main memory. conzept 16 only loads the code from the database that is actually required. Using this method, a procedure can be executed independently of the available memory resources; the developer does not need to worry about code management. For certain applications, it is nevertheless helpful to know the mechanisms of the P-code cache.
Generation of procedure code and runtime data
The P-code generated during the translation of a procedure is not stored in one piece, but consists of a number of 2 KB code blocks that can later be managed independently of each other. Additional metadata is required to execute the individual functions. This metadata is also generated during procedure translation, but is stored separately from the procedure code in the database. This metadata includes, for example, the names, argument types and start addresses of the individual sub-functions, names and sizes of the global data areas and variable information for the debugger.
Loading and executing
Before the first instruction of a procedure is executed, the basic metadata for the subfunctions must first be loaded. The name of the sub-function is used to determine the start address and therefore the required code block for the procedure. This code block is then loaded from the database into the P-code cache if it is not already there. Processing of the P-code then starts. Each time the program jumps from the current code block, the required code block is determined using the target address and then loaded.
Cache management
There is a common buffer memory for the code blocks of all procedures, the size of which is independent of the total amount of procedure code in the database. The buffer fills up automatically during the course of the procedure calls. If the buffer is completely filled, the longest unused block is removed from the buffer when another code block is loaded. If the buffer size is too small, the same code blocks have to be loaded several times during processing, which naturally slows down processing speed and increases network traffic. From version 5.7.08, the maximum amount of buffered metadata is linked to the buffer size. In all previous versions there is a static restriction.
Standard sizes
The default size is defined differently depending on the client type. The default size depends on how many instances of the P-code cache there typically are on a computer and whether procedures for the GUI are also executed. As of version 5.7.08, there are therefore three different size specifications (the API DLL does not use a standard size):
8 MB (GUI / few instances)
– Standard Client
– Advanced Client
– 3.x Client
– Jobs in these clients
2 MB (without GUI / many instances)
– SOA
– Jobs in SOA Service
– PHP
– Print processor
– Server
256 KB (without GUI / no separate address space)
– ODBC
– Web interface
Changing the buffer size
With two new properties of the _Sys object, the current size of the P-code cache can be queried and changed (_Sys->spProcCacheLimitKB), and the current buffer allocation can also be determined (_Sys->spProcCacheKB). The buffer can be enlarged or reduced during operation. The maximum size is 64 MB, the minimum is 256 KB.
More buffer
It makes sense to enlarge the buffer if significantly more code is loaded within an application component than fits into the standard buffer. To determine this quantity, for example, the application is started, the P-code cache is set to maximum size _Sys->spProcCacheLimitKB # (1024 * 64) and the most important functions of a component are executed. Finally, the current size is queried. The client must then be restarted for the next application component, as otherwise the previously loaded procedure code will naturally remain in the buffer. The values determined can then be used to decide whether a higher maximum value is appropriate for the application. This should then be set within the initialization procedure of the application. Alternatively, the limit for the SOA service can also be set in the configuration file of the task.
Less buffer
Reducing the buffer is only necessary in cases where a large number of instances are running simultaneously and little memory is available, for example with numerous database users in the SOA socket task or many jobs in the standard or advanced client.