Yes, that is possible, and saving the compiled code as a RProc is the right way to do it.

One thing to clear up first: mrb_parse_file only gives you the parse tree (AST), not bytecode. The compile step is a separate call. The pipeline is:

1. mrb_parse_file(mrb, fp, c) returns a mrb_parser_state* (the AST).
2. mrb_generate_code(mrb, parser) compiles that AST and returns a struct RProc*. This proc holds the bytecode (its irep).
3. mrb_load_proc(mrb, proc) runs the proc at top level and returns the result. You can call it as many times as you like, with no reparsing and no recompiling.

mrb_load_irep is a different thing: it loads a serialized .mrb byte buffer (the format mrbc produces) and deserializes it on every call, so it is not what you want for in-memory reuse.

A sketch:

mrb_ccontext *c = mrb_ccontext_new(mrb);
mrb_parser_state *p = mrb_parse_file(mrb, fp, c);
struct RProc *proc = mrb_generate_code(mrb, p);   /* the compiled code */
mrb_parser_free(p);
mrb_ccontext_free(mrb, c);

/* The proc is a GC object. A plain C pointer does not keep it alive, and
   each run can trigger GC, so register it before reusing it. */
mrb_gc_register(mrb, mrb_obj_value(proc));

/* run it any number of times */
for (int i = 0; i < n; i++) {
  mrb_value result = mrb_load_proc(mrb, proc);
  /* ... */
}

/* when you are done with it */
mrb_gc_unregister(mrb, mrb_obj_value(proc));

If instead you want to persist the bytecode across separate process runs, the usual path is to compile to a .mrb file with the mrbc tool offline and then load it at runtime with mrb_load_irep_file (or mrb_load_irep from a buffer). But if everything stays in one process, keeping the RProc as above is simpler and faster.