BARfly Help

BARfly Help - Options Menu - Memory and BAR_Services settings

Memory and BAR_Services settings

Select Options.BAR_Services Settings to bring up the dialog box to the left. From this dialog, you can modify BAR_Services initialization settings.

These settings are the same as those required to initialize a BAR_Services interfacial object. Even though BARfly does not allow you to call such an initialization function directly, the parallels between the function call parameters and the fields in this dialog box make the interface almost ubiquitous.

One BAR_Services instance is guaranteed to exist when BARfly starts up. If desired, the user can adjust the memory settings to create a second instance for data file management, isolating the first instance to just the BARfly front-end.

It is actually the Memory Settings selected in the memory dialog box, opened via Options.Memory, that control the initial BARfly memory size settings. For all other BAR_Services creation requests, the value entered into the "Memory Size" field of the BAR_Services Settings dialog box is used.

Setting these fields to nonsensical values can prevent BARfly from starting up properly again. Use the "Reset to Defaults" button to restore all fields to default settings, which are guaranteed to work.

Select Options.Memory to bring up the dialog box to the right. From this dialog, you can modify memory settings associated with BARfly startup. In order to get modified settings to take effect, you must close BARfly and restart it.

Initial memory for BARfly startup: The number of bytes to allocate to BARfly initially. It is recommended that this value be at least 4 megabytes (4,000,000 bytes).
Maximum BAR_Services instances: The maximum number of slots to reserve for BAR_Services instances. Between one and two are created at startup; you can create any number of additional instances if your system has enough memory.
Maximum memory for log: The maximum number of bytes the log can hold. This doesn't need to be very much, since you are normally only concerned with the last several lines of the log. A value of 65,000 is reasonable.
Maintain separate BAR_Services instances for internal BARfly operations and data files: This option creates a second BAR_Services instance after the first one during application startup. The size used for this instance is set in the field below the check box. It is recommended that this value be at least 1 megabyte (1,000,000 bytes)

If you are unable to restart BARfly, you can delete "BARfly.cfg" in the installation directory to restore all settings to their defaults the next time BARfly is started up.

An explanation of BAR_Services settings

Fundamental limits
- Memory Size: This is the total byte size allocated to the BAR_Services instance on initialization. The memory space needed for node handles, BAR instances, BAR_Registry instances, and other support structures is deducted immediately from this total, leaving the remainder of this memory for general use.
- Stack Size: This is the byte size of the stack used while running I.F. functions. The stack size chosen should be commensurate with the complexity of the functions being called in I.F. functions. A value of 2,000 is adequate for nearly all cases, although it may be necessary to increase it if some implementation files cause stack overflow errors.
- Max Nodes: This is the number of node handles allocated to the BAR_Services instance. BARfly reserves some node handles for its own internal logic, but deserialized data files take up the bulk of node handles. The more complex a data file is, the greater its node handle usage requirements. Each node handle requires 24 bytes of memory, which is carved out of the Memory Size total on initialization.
- Max BAR_Registry Instances: This is the most number of registry objects that can be supported simultaneously for the BAR_Services instance. Each time a registry tab is opened, one of these objects is taken up.
- Max BAR Instances: This is the most number of BAR objects that can be supported simultaneously for the BAR_Services instance. Each time a data file is opened, one of these objects is taken up. Some BAR instances are also used internally by BARfly on a piecemeal basis, such as in the execution of I.F. functions for implementation files. This value should be kept high, as the data overhead required for a BAR instance is fairly low.
Read/Write Limits
- Max File Read Size: This is the largest data file read size that the instance can support. Increase this if you are working with large files.
- Max File Write Size: This is the largest data file write size that the instance can support. Increase this if you are working with large files.
- Max "Deserialize" Output: During deserialization, individual "Deserialize" methods are only allowed to cumulatively allocate up to a maximum of this number of bytes.
- Max "Serialize" Output: During serialization, individual "Serialize" methods are only allowed to cumulatively allocate up to a maximum of this number of bytes.
- Max File Read Time: This is the largest amount of time, in milliseconds, that the instance allows for deserialization. You should keep this value to a time long enough to allow most files to finish loading, but not so long as to allow a deadlocked load. A value between 4 and 16 seconds is recommended.
- Max File Write Time: This is the largest amount of time, in milliseconds, that the instance allows for serialization. You should keep this value to a time long enough to allow most files to finish saving, but not so long as to allow a deadlocked save. A value between 4 and 16 seconds is recommended.
Security Settings
- "Opt-in" Path: This is an optional disk path fragment used to restrict the paths of files that can be loaded or saved. Multiple paths can be separated by semicolons. If an opt-in path is specified, all loads of data files must have the first part of its absolute pathname matching one of the opt-in path fragments, or else the load operation will fail. If there is no opt-in path specified, all paths are opted in.
- "Opt-out" Path: This is an optional disk path fragment used to restrict the paths of files that can be loaded or saved. Multiple paths can be separated by semicolons. If an opt-out path is specified, all loads of data files must not have the first part of its absolute pathname matching one of the opt-out path fragments, or else the load operation will fail. If there is no opt-out path specified, no paths are opted out.
Engine Control Flags
- Memory Bounds Test: Test memory access bounds while executing I.F. functions. Unchecking this option may improve performance. It is strongly suggested you leave this checked.
- Stack Overflow Test: Test for stack overflow while executing I.F. functions. It is strongly suggested you leave this checked.
- Math Domain Test: Test for mathematical domain errors while executing I.F. functions. It is strongly suggested you leave this checked.
- Opcode Validity Test: Test for opcode/mod byte logic errors while executing I.F. functions. Unchecking this option may improve performance. It is strongly suggested you leave this checked.
- Ignore Breakpoints: If checked, all breakpoints in I.F. functions are ignored. If unchecked, breakpoints in I.F. functions halt function execution.
Opcode Execution Limits
- Max Read Cycles: This limits the total amount of opcode execution iterations of I.F. functions during deserialization. Complex functions called by critical steps will take more cycles than those functions that are relatively simple. Increase this value if you are working with complex I.F. functions and/or very large, complex data files.
- Max Write Cycles: This limits the total amount of opcode execution iterations of I.F. functions during serialization. Complex functions called by critical steps will take more cycles than those functions that are relatively simple. Increase this value if you are working with complex I.F. functions and/or very large, complex data files.
- Max Overall Cycles: This limits the total amount of opcode execution iterations of I.F. functions during a single function execution session. The limit applies to I.F. functions called by critical steps as well as those called by invoking Run.Run I.F. function.

Creating and managing BAR_Services instances

Select File.Manage BAR_Services instances to bring up the dialog box to the left. From this dialog, you can create, analyze, select, and remove BAR_Services instances.

To view the associations (data files and other views) of all BAR_Services instances, select the line in the list and click the View Associations button. Click the button again to display the list once more.

To view memory blocks of a particular instance, select the line in the list and click the View Memory button.

You can create a new instance (if an instance slot is free) by clicking New Instance. You can also create a new instance without opening this dialog by selecting File.Create BAR_Services instance from the menu.

You can destroy a BAR_Services instance by selecting the instance and clicking Destroy Instance. This action will close all views dependent on the BAR_Services instance. This is a high-level, data-destructive button whose functionality should not be taken lightly. Cancelling the closing of an unsaved file will halt the instance destruction operation.

The initial BARfly instance is a special case--it cannot be destroyed. BARfly uses BAR to drive its internal architecture, so this instance cannot go away unless the application is itself closed.

Any time you want to create a data file in a specific BAR_Services instance, simply select the instance and close the dialog box. All subsequent invocations of File.New Data File and File.Open Data File will cause the data file to exist in the explicitly selected instance. While not necessary in most cases, sometimes it is beneficial to isolate different types of data files in their own memory spaces in this fashion.