βΉοΈ This blog post was created with the assistance of AI to help explain Uniface concepts in simple terms.
π What is Component Memory Management?
When you run a Uniface application, component instances need memory to work. This memory stores two main things:
- Component Definition - The blueprint of your component
- Component Data - The actual data your component is working with
The interesting part? π€ This memory doesn't always get freed when you delete a component instance. Uniface can actually reuse it!
πΎ How Component Definitions Work
The first time you create a component instance using newinstance
, activate
, or run
, Uniface loads the component definition from your file system into memory. Think of it like opening a blueprint for the first time.
Example:
; First time - loads definition into memory
activate "MyForm".exec
; Second time - reuses the definition already in memory
activate "MyForm".exec ; Faster startup!
The memory size of a component definition is roughly the same as the uncompressed size of the component file (.dsp, .svc, etc.).
βοΈ The Component Behavior Property
You can control how Uniface handles component memory using the Component Behavior property. This is important to avoid memory leaks! π¨
Best Practice:
Unless you specifically need to reuse component definitions, set the Component Behavior to "Drop component definition from memory". Otherwise, the definition stays in memory even after deletion, causing memory leaks.
Example Settings:
- β Drop component definition from memory - Recommended for most cases
- β οΈ Keep component definition and data in memory - Only for forms started with
run
command that you want to reuse
π Component Data in Memory
Component data is the information your component loads from databases or files. This includes:
- Database records
- Component-level properties
- Entity-level properties
- Field-level properties
The amount of memory needed depends on how much data you fetch. This data is only available within the scope of the component instance.
β οΈ Important Note:
If you keep component data in memory (using "Keep component definition and data in memory"), there's no guarantee that this data stays synchronized with your database. This means the data in memory might become outdated! π
π― When Should You Reuse Component Memory?
Memory reuse is intended for:
- β
Form components started with the
run
command - β Modal forms (common in older Uniface applications)
- β Forms that access large amounts of data
Memory reuse is less suited for:
- β Modern component-based applications
- β Applications using
newinstance
to create multiple instances - β Purpose-specific component types
Why? π€·
Because it violates the central principle of component-based development: a component instance and its data should form a modular, cohesive unit.
π‘ Practical Example
; Bad practice - can cause memory leak
activate "CustomerForm".exec("CustomerInstance")
; Component definition stays in memory after deletion
deleteinstance "CustomerInstance"
; Good practice - set Component Behavior property
; to "Drop component definition from memory"
; Now the definition is properly cleaned up!
π Key Takeaways
- Component definitions are loaded once and can be reused for faster startup
- Always set Component Behavior to avoid memory leaks unless you have a specific reason
- Component data in memory may become out of sync with your database
- Memory reuse works best with traditional
run
command forms - Modern component-based applications should generally not reuse memory
π Conclusion
Understanding component memory management in Uniface helps you build more efficient and reliable applications. Remember to choose the right Component Behavior setting for your use case, and be mindful of potential memory leaks! π‘οΈ
For older applications using modal forms with the run
command, memory reuse can improve performance. For modern component-based applications, it's better to let Uniface clean up memory properly.
Happy coding! π¨βπ»π©βπ»
Top comments (0)