PowerAda Planning the Development Environment

Chapter 5

• Notice
• Chapter 1. Overview
• Chapter 2. Getting Started
• Chapter 3. Basic PowerAda Concepts
• Chapter 4. The PowerAda Development Environment
• Chapter 5. Project Management with PowerAda
• Chapter 6. The PowerAda Debugger: adbg
• Chapter 7. Interface to Other Languages
• Chapter 8. Implementation Details
• Chapter 9. Optimization
• APPENDIX A - Glossary
• APPENDIX B - Support Packages
• APPENDIX C - Implementation Characteristics
• APPENDIX D - Demos and Tutorials
• APPENDIX E - Tools Reference
• APPENDIX F - Debugger Command Reference
• Index

Contents |  Installation Guide | Release Notes

First | Prev | Next | Last

PowerAda is a large suite of powerful tools which can make significant demands on system resources. Here are a few suggestions to help minimize and distribute the load.

Have one central PowerAda installation.

Install PowerAda in as few different places as possible. This simplifies customization and updates, and of course reduces disk space usage. If everyone is using the same Setup File and the same patch level (OC Systems is often able to provide bug fixes to specific programs), configuration problems are minimized.

Users should work on a local disk.

That is, a user's work area should be on a disk that is attached to the machine on which the user is executing PowerAda. This is because, while UNIX is generally efficient in accessing and caching read-only files across NFS, write operations across NFS are much slower, and more likely to cause errors and corruption if there are network problems. Of course, reading from a local filesystem is still much faster than reading from an NFS-mounted one, so the ideal configuration would have baseline projects on locally-mounted disks as well.

Provide enough physical and virtual memory.

The PowerAda compiler allocates a lot of memory, especially when optimizing or binding large programs, and the powerada GUI also keeps a cache in memory to speed up searches. The programs will fail with Storage_Error, or simply be killed by the operating system, if there is insufficient virtual memory (paging space). The command

lsps -a

will show the available and active paging space. There should be at least twice as much paging space as physical memory, and it should reside on your fastest local disk.

If there is sufficient paging space, big-memory programs will run, but if there is not enough physical memory, the programs will be slow. Paging can really eat into system response time, and reduce user productivity. Furthermore, AIX caches files in memory, so having enough to map entire PowerAda libraries can greatly increase performance across NFS.

More specifically, 64MB of virtual memory and 32MB of physical memory are the minimum base requirements for PowerAda. For each additional developer on that machine, add that same amount: 64MB of paging space and 32MB of physical memory. So if you have 10 developers, roughly 256MB of physical memory and 640MB of paging space should be available. Obviously, as the number of developers increases this marginal cost goes down, because the opportunity for sharing increases, and not all developers will be using memory-hungry operations simultaneously. However, you can never have too much memory, and putting more memory on a machine often gets more of an increase than increasing CPU speed.