— Function: char* profile_path_make_opts char* options, char* name, char* version, char* extension
— Function: char* profile_path_make char* name, char* version, char* extension

Prepare a directory and return a file name (actually a path) suitable for writing profile information. The functions return a pointer to a string; it should be freed when no longer needed. For profile_path_make the directory and file name are chosen in the same way as for the `Profile' class when instantiated with mode set to read except that the path name ends with extension rather than .pro. Function profile_path_make_opts is similar, except its as though mode were set to read:options.

The directory will be created if not present, however nothing will be done with the file itself. That is, no attempt will be made to open the file or to see if it already exists.

In the example below a file name is constructed and used for free-form output.

            // File name will contain name of benchmark.
            char* const pname = profile_path_make("pp_name","pp_ver","txt");
            pp_file = fopen(pname,"w");
            fprintf(pp_file,"This is my file so I'll write data my way!\n");
          
            // File name will contain full benchmark id.
            char* const pname2 =
              profile_path_make_opts("per=benchmark-id","pp_name","pp_ver","txt");
     

— Class: Profile char* mode, char* name, char* version

Construct a profile object, open a profile file, and start reading or writing it. Argument mode must start with `read', `write', or `read/write'. It may also be followed by options in the form opt=val:...

If mode is `read', file will be read; `write', file will be written; and if `read/write' then file will be read and then written. To determine if file was successfully open use file_is_open.

If `per=benchmark-id' is present then profile file names are constructed using the entire benchmark id. If `per=per-benchmark-name' is present or if there is no `per' option, then profile file names use the first two components of the benchmark id.

Argument name specifies the name of the profiler (which can be anything valid in a file name). The file will be placed in a directory named name which is a subdirectory of the directory pointed to by RTI profile_dir. Argument version specifies a profiler version, this is used to name the profile file. Note that name and version are used only for locating the profile file.

Suppose RTI profile_dir is set to `"/home/jones/profile"' and that benchmark `gentest' is being run, then the name of the profile file will be: `/home/jones/profile/ez-hybrid/gentest-1.0.pro'.

If mode is `write' then a header will be written, if mode is `read' or `read/write' a header will be read and execution will end with a fatal error if the byte order (big or little endian) or data model (size of integers, etc.) don't match.

The file will be closed when the Profile object's destructor is called.

The examples below show file naming differences obtained with the `per' option. The difference is significant when running a batch with, say, benchmark id's lsu.gentest.debug.xmr and lsu.gentest.production.abc. The profile1 object would use different files for those, while profile2 would use the same file names.

              Profile profile1("write:per=benchmark-id","sp-diff","hello");
          
              // Writes file:
              //    .../profile/sp-diff/lsu.gentest.debug.xmr-hello.pro
          
              Profile profile2("write","sp-diff","hello");
          
              // Writes file:
              //   .../profile/sp-diff/lsu.gentest-hello.pro
     

— Function: void Profile::init char* mode, char* name, char* version

Initialize profile object. Can only be used if profile constructed with void constructor.

— Function: bool Profile::file_is_open

Return `true' if file was successfully open, `false' otherwise. If the file was not successfully open and any data access function is used execution will exit with a fatal error.

— Function: char* Profile::profile_file_path_get

Return the path of the profile file. The string will be destroyed with the profile object.

In the example below the profile file is deleted (unlinked) after it is read. Note that a copy of the path is made because the value returned by profile_file_path_get is not valid when the Profile object is destroyed, at the end of the enclosing block.

            RString profile_file_path;
          
            {
              Profile profile("read","basic_block_data_temp","1.0");
              profile_file_path = profile.profile_file_path_get();
              profile >> insn_segment_data;
            }
          
            unlink(profile_file_path);
     

— Function: void Profile::mode_to_write

Switch from read mode to write mode. Only valid if profile opened in `read/write' mode.

— Function: void Profile::mode_to_read_zeros

All subsequent calls to functions that read from file will behave as though the file contained all zeros. For objects derived from LObject, this initializes them to an empty state. This might be useful in read-modify-write code for occasions when the data in the file should be discarded rather than read but surrounding the remaining read code with an if statement would destroy the clarity and beauty of your code.

— Function: void Profile::write_obj &object
— Function: void Profile::write_val object
— Function: Profile& Profile::operator << &object

Write object to file. Argument to write_obj and << operator is a reference, so use write_val for constants. If object is derived from LObject then its self_pack function will be used to correctly write it to the file. If not, its contents will be copied, which can be a problem if it contains pointers.

— Function: void Profile::read_obj &object
— Function: T Profile::read_val
— Function: Profile& Profile::operator >> &object

Read object from file. Both read_obj and >> will read directly into the object, which is what you want to do with large data structures. Function read_val will return the object, which is okay for small items like integers and doubles. In addition to the functions above, objects derived from LObject can be initialized using data from the file by using a Profile object as a constructor.

— Function: void Profile::read_or_write &object

Read or write object from file, depending on mode of Profile object. This function allows one to have a single routine for both writing and reading a profile, eliminating the possibility of inconsistency.

            Profile profile;
            profile.init( train_mode ? "write" : "read", "ez-hybrid", "1.0");
            profile.read_or_write(case_x_count);
            profile.read_or_write(case_y_count);
            profile.read_or_write(sin_info);
     

— Function: void Profile::write_array T* array int num_elements

Write array of num_elements starting at array of elements of type T.

— Function: void Profile::read_array T&* array int& num_elements
— Function: void Profile::read_array T&* array int num_elements

Read array of elements of type T. If array is `NULL' then storage will be automatically allocated. If num_elements is non-zero or if the second form is used (where the type is not a reference) then execution will end with a fatal error if it differs from the number of elements read from the file. If num_elements is zero it is written with the number of elements read from the file.

— Function: void Profile::read_or_write_array T&* array int& num_elements
— Function: void Profile::read_or_write_array T&* array int num_elements

Read or write array, depending on profile mode. See read_array and write_array.