Improvements for gs2_init

We use gs2_init to control the initialisation level of gs2 (i.e. the current initialisation state of the code).

There are several small enhancements which might be helpful to include

Currently one needs to use the init method of the module on an init_type instance with an init_level_list value to set the target level. It might be helpful to bind the init method to the type.
The init method decides if we’re increasing or decreasing the current level and then calls routines in different orders depending on the direction. The order is important and must match (or reverse) the init_level_list. We should be able to rewrite this as a loop from current_level to target_level (with step +/- 1 depending on direction) such that the order of call statements is not important. This will reduce duplication in the generated code.
The generated code currently consists of calling a routine for each level with a flag to indicate if we’re going up or down. This code must initialise/finalise the objects held at that level. It’s not possible for there to be any introspection here. It would perhaps be useful to introduce an init_level_type type which has the relevant initialise/finalise code bound to it. This would then allow the init_level and a readable name to be stored alongside the method, potentially aiding neater code.
We could add timers to the initialise/finalise routine so that we can obtain a breakdown of initialisation time. This could be helped by the introduction of init_level_type.

‌

Comments (1)