Paper deep dive
Accelerated Genetic Programming Hyper-Heuristics for Simulation-Based Scheduling via Agentic AI
Heyang Thomas Li, Alexander Pletzer, Yuan Tian, Yi Mei, Mengjie Zhang
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 94%
Last extracted: 8/21/2026, 3:12:51 AM
Summary
This paper presents a systematic approach to optimizing Python-based discrete-event simulation code for Genetic Programming Hyper-Heuristics (GPHH) in resource-constrained project scheduling. By leveraging Claude agentic AI to identify bottlenecks and implement targeted optimizations—including runtime cleansing, precomputed static maps, incremental resource propagation, and Numba compilation—the authors reduced simulation runtime from 1,298 seconds to under 200 seconds. This optimization saved approximately four million core-hours and NZ$320,000 annually in a high-performance computing environment, demonstrating the efficacy of human-agent collaboration in performance engineering.
Entities (7)
Relation Signals (5)
Optimization Strategies → reducedruntime → 1298s to 200s
confidence 98% · Testing runtime reduced from 1,298 seconds to under 200 seconds
GPHH → solves → DMRCPSP
confidence 95% · This case study focuses on the dynamic multi-mode resource-constrained project scheduling problem (DMRCPSP)... To automate rule design, this project implements a Genetic Programming Hyper-Heuristic (GPHH) framework
Claude → usedforoptimization → Python Code
confidence 95% · This paper presents a systematic refactoring approach using Claude agentic AI on real-world project-scheduling workloads
Numba → usedtoaccelerate → Python Code
confidence 92% · Use primitive types and contiguous arrays... execute loops as LLVM machine code. Impact: −184 s
Python → suffersfrom → Performance Overhead
confidence 90% · its interpreted and dynamically typed execution model can impose substantial performance overhead
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Python is widely used in scientific research because it enables rapid development and provides rich ecosystems for data analysis, artificial intelligence (AI), and machine learning. However, customized research code can become prohibitively slow as experiments scale. This challenge is particularly acute in discrete-event project-scheduling simulations, where sequential state updates, nested loops, conditional evaluations, and object-oriented structures limit the benefits of compiled numerical and GPU-accelerated libraries. Addressing these bottlenecks typically requires iterative profiling, refactoring, testing, and validation, yet researchers may lack the time or specialized software-engineering expertise for low-level optimization. This paper presents a systematic refactoring approach using Claude agentic AI on real-world project-scheduling workloads in a high-performance computing (HPC) environment. Guided by representative benchmarks and correctness checks, the agent identifies bottlenecks, implements targeted optimizations, and evaluates their effects, while the researcher retains final control. Testing runtime reduced from 1,298 seconds to under 200 seconds without changing outputs, saving four million core-hours (NZ\$320,000) annually.
Tags
Links
- Source: https://arxiv.org/abs/2608.19487v1
- Canonical: https://arxiv.org/abs/2608.19487v1
Trouble viewing inline? Open PDF directly →
Full Text
53,693 characters extracted from source content.
Expand or collapse full text
Accelerated Genetic Programming Hyper-Heuristics for Simulation-Based Scheduling via Agentic AI Heyang Thomas Li Research Engineering Team REANNZ New Zealand thomas.li@reannz.co.nz heyang.li@anu.edu.au Alexander Pletzer Research Engineering Team REANNZ New Zealand alexander.pletzer@reannz.co.nz Yuan Tian Centre for Data Science and Artificial Intelligence & School of Engineering and Computer Science Victoria University of Wellington New Zealand yuan.tian@vuw.ac.nz Yi Mei Centre for Data Science and Artificial Intelligence & School of Engineering and Computer Science Victoria University of Wellington New Zealand yi.mei@vuw.ac.nz Mengjie Zhang Centre for Data Science and Artificial Intelligence & School of Engineering and Computer Science Victoria University of Wellington New Zealand mengjie.zhang@vuw.ac.nz Abstract—Python is widely used in scientific research because it enables rapid development and provides rich ecosystems for data analysis, artificial intelligence (AI), and machine learning. However, customized research code can become prohibitively slow as experiments scale. This challenge is particularly acute in discrete-event project-scheduling simulations, where sequential state updates, nested loops, conditional evaluations, and object- oriented structures limit the benefits of compiled numerical and GPU-accelerated libraries. Addressing these bottlenecks typically requires iterative profiling, refactoring, testing, and validation, yet researchers may lack the time or specialized software-engineering expertise for low-level optimization. This paper presents a systematic refactoring approach using Claude agentic AI on real-world project-scheduling workloads in a high-performance computing (HPC) environment. Guided by representative benchmarks and correctness checks, the agent identifies bottlenecks, implements targeted optimizations, and evaluates their effects, while the researcher retains final control. Testing runtime reduced from 1,298 seconds to under 200 seconds without changing outputs, saving four million core-hours (NZ$320,000) annually. Index Terms—Performance engineering, agentic AI, genetic programming hyper-heuristics, resource-constrained scheduling, high-performance computing, Python. I. INTRODUCTION As the Python ecosystems for data analysis, artificial in- telligence (AI), and machine learning (ML) have contin- ued to expand and mature, Python has become a preferred programming language for many researchers because of its accessibility, rapid development cycle, and extensive library support. However, its interpreted and dynamically typed exe- cution model can impose substantial performance overhead. Optimized libraries such as NumPy [1] and PyTorch [2] mitigate this limitation by executing computational kernels in compiled code or on GPUs. Such acceleration is less straightforward for applications with complex control flow, including discrete-event simulations, where execution involves numerous loops, conditional evaluations, state updates, and sequentially dependent events that cannot easily be expressed as vectorized array or tensor operations. This limitation is particularly consequential when AI algorithms are used to automate the design of heuristic rules for dynamic scheduling. During training, the algorithm generates and evaluates a large number of candidate rules, each of which must be assessed through repeated simulation. Consequently, simulation often becomes the dominant computational bottleneck. Access to high-performance computing infrastructure can increase ex- perimental throughput, but it does not eliminate the underly- ing technical debt: inefficient simulation code still consumes excessive CPU time and energy, limits the number and scale of experiments, and increases the cost of scientific discovery. This performance engineering project was initiated to ad- dress severe resource exhaustion on a compute cluster man- aged by Research and Education Advanced Network New Zealand (REANNZ). According to REANNZ systems support team: “The project had been renewed for 1,054,000 com- pute units for the year from 2026-09-01. However, over the last year it used ̃5,173,000 compute units.” Unchecked, the project consumed roughly five times the number of compute units (a compute unit roughly matches a core-hour). This paper details the performance engineering strategies used to bring the project back into acceptable computational bounds while improving research throughput and reducing operational cost. This situation reflects a broader tension in research soft- arXiv:2608.19487v1 [cs.SE] 19 Aug 2026 ware. Research emphasizes novel concepts, mechanisms, and scientific results, so implementation efficiency often becomes secondary once a proof of concept produces valid outputs. Performance engineering is also iterative and time-consuming, requiring representative benchmarks, profiling, repeated mod- ifications, and correctness and runtime checks. Domain re- searchers may also have limited formal software-engineering training [3]. Agentic coding assistants offer a way to lower this barrier. Claude Code [4] and CodeX [5] can inspect repositories, edit files, and run profilers and tests. Their emergence accompa- nies “vibe coding,” or developing software through natural- language interaction with a code-generating model [6]. Beyond generating code, an agent can explore alternatives, automate repeated benchmarks, compare measured effects, and discuss trade-offs with the researcher. Agentic AI nevertheless cannot reliably optimize scientific software from a single wish-like prompt. A change may alter numerical results, move the bottleneck, or improve a micro-benchmark without reducing end-to-end runtime. Our contribution is therefore a practical human–agent workflow, demonstrated on a Genetic Programming Hyper-Heuristic (GPHH) code for simulation-based scheduling 1 . A trusted benchmark establishes runtime and solution checksums; the agent profiles the program, proposes scoped changes, and tests their effects; and the researcher reviews each implementation and independently accepts or rejects it. This disciplined loop turns unconstrained code generation into evidence-based per- formance engineering and delivers substantial efficiency and economic gains without changing the scheduling algorithm or its outputs. The remainder of this paper covers the scheduling and simulation background (Sec. I), the DMRCPSP case study and GPHH decision process (Sec. I), and the human–agent workflow and optimization strategies (Sec. IV), followed by their measured impact and conclusions. I. BACKGROUND AND RELATED WORK A. Societal and Economic Impact in Planning and Scheduling Planning and scheduling allocate scarce resources over time, with consequences beyond completion time. In emergency medical services, ambulance dispatch and relocation affect response times [7]. Genetic programming hyper-heuristics have recently produced interpretable rules for vehicle-subset selection and interdependent dispatch decisions [8], [9]. A cohort study of out-of-hospital cardiac arrests predicted that reducing the response-time target from 14 to 8 minutes would increase survival from 6% to 8%, while a five-minute target would increase survival to 10–11% [10]. Health-care planning also coordinates operating rooms, beds, diagnostic services, and staff, affecting access and waiting times [11]. The economic and environmental consequences are simi- larly substantial. A dynamic job-shop study reported makespan reductions of 2–17% and machine-utilization improvements of 1 The source code is available at github.com/TianYuanSX/GP4MRCPSP 2–21% after adapting dispatching rules to changing conditions [12]; power-system load scheduling can improve both market outcomes and energy use [13]. This impact extends from recurring operations to projects, where scheduling coordinates interdependent activities and resources. A construction case study, for example, reported that resource-aware scheduling improved duration by 6.25% and profit by 8% [14]. Such settings motivate the use of a resource-constrained project scheduling problem (RCPSP) approach, a standard abstraction for resource-constrained project planning. B. RCPSP Complexity and Evolutionary Computation The resource-constrained project scheduling problem (RCPSP) comprises precedence-related activities with given durations and demands for limited renewable resources. It assigns start times that respect precedence and resource capaci- ties, usually to minimize project makespan [15]. RCPSP-based models support planning in manufacturing, supply chains, software projects, and aircraft maintenance [16]–[19]. Even the classical RCPSP has non-polynomial (NP) com- plexity [20]. Its difficulty arises because precedence and resource constraints couple the start-time decisions: starting one activity can delay several others that require the same resources. The number of candidate activity sequences grows combinatorially with project size, while each sequence must also be checked for temporal and resource feasibility. Exact methods can therefore become impractical as the number of activities and constraints increases. Even a recent compact ex- act formulation for robust MRCPSP, although markedly faster than prior approaches, was tested only up to 20 activities; it solved on average 88.1% of those instances to optimality within two hours, falling to 86.3% at the highest uncertainty level [21]. Evolutionary computation (EC) explores these large spaces under a finite computational budget. Competitive and hy- brid genetic algorithms have produced high-quality RCPSP schedules on benchmarks [22], [23]. Genetic programming (GP) is instead used as a hyper-heuristic: it evolves reusable priority rules that construct schedules from the current state and has been effective in complex, dynamic scheduling [24], [25]. Their rules are inexpensive to apply online, but training remains costly because thousands of candidates must be evalu- ated over many simulated instances and stochastic realizations. C. Simulation-Based Evaluation and Acceleration Challenges For realistic dynamic scheduling, heuristic-rule quality is often estimated using discrete-event simulation (DES) [26]. Python is attractive for developing such models because its concise syntax and flexible object model support rapid pro- totyping and iterative refinement. Its broad ecosystem also allows data preparation, statistical analysis, graph processing, visualization, and learned heuristic rules to be implemented in one environment using packages such as pandas [27], NumPy [1], NetworkX [28], and PyTorch [2]. The trade-off is execution speed. CPython incurs overhead from bytecode dispatch, name and attribute lookup, dynamic ✓ ✓ ➢ ❖ ❖ Fig. 1. Overview of the Dynamic Multi-mode Resource-constrained Project Scheduling Problem (DMRCPSP): a capacity-limited resource pool, a project breakdown structure with precedence and resource constraints, and stochastic activity durations. type handling, reference counting, and garbage collection [29]. These costs become substantial in fine-grained loops that repeatedly create objects or invoke small functions. High-level packages can introduce further overhead because their general- purpose interfaces support flexible data structures, validation, conversion, iterators, and rich abstractions. Although numeri- cal libraries execute large kernels efficiently in compiled code, repeated small library calls, temporary arrays, and transitions between Python and native code may prevent that cost from being amortized. Sequential DES magnifies these effects by executing the event and decision logic many times. Several approaches can accelerate Python simulation, but each has limitations. Independent replications and heuristic- rule evaluations can run in parallel, but scaling this approach requires many CPU cores and duplicates simulation state in memory. Parallel DES can distribute a single simulation, but must preserve causality through conservative or opti- mistic synchronization [30]. GPUs provide greater parallel throughput, yet fine-grained DES maps poorly to them be- cause events update the state required by later decisions and cause asynchronous advancement, synchronization, irregular memory access, and branch divergence [31]. A third approach is to compile selected performance hots pots to native code with tools such as Numba [32] or Cython. This removes interpreter overhead without rewriting the entire simulator. For Numba in particular, efficient compilation requires well- defined types and supported control flow; dynamic containers, arbitrary Python objects, and object-oriented features have limited support and often must be converted into primitive values and contiguous arrays [32]. I. CASE STUDY DOMAIN: GPHH FOR DMRCPSP A. DynamicMulti-ModeResource-ConstrainedProject Scheduling Problem (DMRCPSP) This case study focuses on the dynamic multi-mode resource-constrained project scheduling problem (DMR- CPSP), illustrated in Fig. 1. It extends the RCPSP in two ways. First, each activity can be executed in one of several modes with different expected durations and resource de- mands [33]. Second, an activity’s actual duration is uncertain and is revealed only during execution. Scheduling decisions must therefore be made online: as the project state changes, heuristic rules select feasible activity–mode combinations from the currently eligible set. The objective is to minimize ex- pected makespan while satisfying precedence and resource constraints. B. Decision-Making Workflow and Heuristic Rules for DMR- CPSP The DMRCPSP decision-making workflow [34] is shown in Fig. 2 . This figure also connects the event-driven simulation workflow to its Python implementation and summarizes the performance issues and corresponding solutions identified through the Agentic-AI-assisted optimization process. The simulation first initializes the activity states, stochastic du- rations, and resource-availability timeline. At each decision point, completed activities are recorded, their resources are re- leased, and the eligible set is updated to contain activity–mode pairs whose precedence and resource requirements permit an immediate start. Schedule construction then makes two types of heuristic decisions, illustrated by the evolved-rule example in Fig. 3: 1) Activity–mode ordering: An ordering rule scores and ranks all eligible activity–mode pairs. Only the highest- ranked mode for each activity is retained, and knee- point selection identifies a promising subset for further consideration. 2) Activity-group selection: Combinations of the promis- ing pairs are enumerated and resource-infeasible groups are removed. A group selection rule scores the remaining groups and selects one group for concurrent execution. The selected activities are started, their realized durations are sampled, and their resource demands are reserved. When no additional activity can start at the current time, the sim- ulation clock advances to the next activity-completion event. The state and eligible set are then updated and the proce- dure repeats until every activity is completed. Consequently, ordering-rule evaluation, feasible-group enumeration, group- rule evaluation, and resource-feasibility checks are repeatedly executed within a single simulation, making this loop a major contributor to total runtime. C. Evolving Heuristic Rules via Genetic Programming To automate rule design, this project implements a Genetic Programming Hyper-Heuristic (GPHH) framework [24], [25] that evolves the two priority rules simultaneously. Candidate rule pairs are modeled as mathematical expression trees using simulation state variables (terminal sets) and operators (func- tion sets), as shown in Fig. 4. During training, each pair directs all scheduling and mode choices within the Python simulator across a suite of DMRCPSP instances. The resulting makespan determines evolutionary fitness. Because the outer GPHH loop evaluates thousands of trees over millions of nested simulator iterations, internal Python interpretive overhead compounds exponentially, causing severe cluster resource exhaustion. Decision-making procedureCode implementationLegacy issue identifiedOptimized solution 1. Initialize simulation 2. Advance event and update state active / completed / queued / eligible task set resource usage 3. Select promising activity-mode pairs activity ordering rule + knee point selection 4. Enumerate feasible activity groups branch-and-bound under current resources 5. Select an activity group activity group selection rule 6. Start selected activities sample duration and update resource availability Advance to next completion event t ← min(active finish times) Project completed? Return makespan / schedule buildSolution() Create active, queued and completed sets; resource timeline; durations; finish times; feature cache. updateStatus() → updateEligible() Start queued work; call earliestStart() for each precedence-feasible activity-mode pair; compute dynamic CPM. activity_subset_selection_knee_point() Evaluate ordering GP tree; sort pairs; keep best mode per activity; retain pairs up to the knee. activity_group_selection_tree_enumeration() Expand a heap-based search tree; check each partial group against resources; prune infeasible children. priority_func() on candidate groups Set cur_combination, clear feature cache, evaluate the selection GP tree, and retain the minimum-cost group. scheduleActivity() + earliestStart() Validate start time, record sampled duration/mode/finish time, and subtract demand from the resource timeline. Event-driven loop updateStatus() jumps to the minimum active finish time; repeat until all tasks complete. Cross-cutting instrumentation overhead Debug logging, search-tree recording, string formatting, and assertions execute inside repeated simulation paths. Repeated dynamic graph abstraction _compute_dynamic_cpm() repeatedly creates NetworkX subgraphs/views and iterators although project topology is static. Full resource recomputation at every node check_feasible() copies the partial group and runs np.sum() over all selected activities for each child expansion. earliestStart() is a numerical hotspot Each call allocates a full temporary subtraction array, creates time-window slices, and scans candidate times in Python. 1. Production runtime cleansing Disable verbose diagnostics and run python -O so __debug__ blocks and assertions are removed. Impact: −511 s 2. Precomputed static adjacency maps Build predecessor/successor dictionaries once; use direct set/list filtering in dynamic CPM instead of runtime NetworkX views. Impact: −273 s 3. Incremental resource-state propagation Store resource_consumed in each heap node; a child performs one vector addition and one capacity comparison instead of summing the full group. Impact: −330 s 4. Numba-compiled earliest-start kernel Use primitive types and contiguous arrays; compare resources directly, exit on the first violation, and execute loops as LLVM machine code. Impact: −184 s End-to-end result 1298 s → 195 s (85% faster) | 5.17M → 1.05M compute units/year | NZ$320k annual saving Yes No Fig. 2. DMRCPSP simulation workflow and summary of the Agentic-AI-assisted code optimization. The decision-making procedure is mapped to its Python implementation, the performance issues identified in the legacy code, and the corresponding optimized solutions. Solid arrows show simulation control flow; dashed arrows link related implementation, issue, and solution components. Fig. 3. Example of an evolved GP individual containing an activity–mode ordering rule (top) and an activity-group selection rule (bottom), each represented as a mathematical expression tree. IV. IMPLEMENTATION & OPTIMIZATION STRATEGIES Figure 5 summarizes the implementation and optimization workflow used in this case study. The first step to improving code performance involves generating a test case, which should be small enough to allow the code to be run many times, yet large enough to capture the large execution time asymptotic behavior of the code. The test should also contain check sums (numbers that are representative of the solution) to ensure that changes do not break the code. Next, performance improvement efforts should involve pro- filing, i.e., identifying parts of a program where most of the execution time is spent. Finding execution bottlenecks allows one to focus attention on parts that are known to contribute most to the runtime. The process is iterative: as each hot spot is addressed, other bottlenecks emerge and need to be suppressed until satisfactory performance is achieved. These two steps lend themselves naturally to automation by an AI coding agent – Claude [4]. The agent can run the test, analyze the profiling output, identify the next hot spot to address, and implement the corresponding code change. Fig. 4. Genetic Programming Hyper-Heuristic (GPHH) framework: candidate priority rules are represented as expression trees, evolved against a benchmark dataset, and evaluated via the simulation model. In this work we instead adopted a semi-automated workflow, in which the agent proposes and applies code modifications while the programmer inspects the output and independently re-measures execution time to confirm that each change is both correct and beneficial. This division of labor mirrors the pair- programming practice advocated by Extreme Programming [35], [36], with the agent taking the role of the “driver” and the programmer that of the “navigator” – except that the driver is a machine. Responsibility for committing changes and opening pull requests remains with the human programmer, who retains final authority over what enters the code base. We categorized the performance engineering efforts into four core strategies, ranking them by algorithmic complexity and resource savings. A. Environmental Runtime Cleansing (Baseline Cleanup) The first optimization phase focused on eliminating avoid- able execution overhead introduced by development-oriented instrumentation embedded within the production workflow. The original implementation had evolved through multiple development cycles and retained several diagnostic mecha- nisms—such as debug-level string evaluations, runtime val- idation checks, and excessive logging operations within the simulation loop—that were valuable during algorithm develop- ment but highly inefficient during large-scale HPC execution. Because the genetic programming hyper-heuristic framework evaluates large populations of candidate solutions through iterative simulation, these individually inexpensive operations were repeatedly triggered across millions of scheduling state evaluations. When aggregated across thousands of evolution- ary generations and repeated scheduling simulations, these small, per-operation overheads within the inner execution loops created massive cumulative computational overhead, directly driving up total HPC resource consumption. a) Action: The first optimization step applied a non- invasive runtime cleansing procedure designed to remove unnecessary production overhead without altering algorithmic behavior or modifying the underlying scheduling logic. The following changes were applied: • Disabled debug-level execution paths. Development- only diagnostic blocks, including verbose logging state- ments, intermediate state reporting, and runtime inspec- tion routines, were deactivated during production execu- tion. These operations were previously executed within high-frequency simulation pathways and contributed un- necessary CPU cycles and memory operations. • Enabled Python optimized execution mode. The ap- plication was executed using Python’s optimized runtime flag: python -O script.py This instructs the Python interpreter to enable optimiza- tion mode by: – removing execution of assert statements, – suppressing generation of debugging metadata, – reducing interpreter-level validation overhead, – generating optimized bytecode (.opt-1.pyc). Importantly, this modification required no changes to the algorithm implementation, data structures, or scheduling model, allowing the impact of environmental optimiza- tion to be isolated independently from later code-level improvements. • Preserved computational equivalence. Since the op- timization only removed non-functional instrumenta- tion, the generated scheduling solutions and evolution- ary search behavior remained unchanged. This ensured that runtime improvements represented genuine compu- tational efficiency gains rather than algorithmic approxi- mation or reduced solution quality. b) Impact: Environmental runtime cleansing provided an immediate improvement in execution efficiency, reducing total simulation runtime from 1,298 seconds to 787 seconds, representing a reduction of 511 seconds (8.5 minutes) per ex- ecution. This corresponds to an approximately 40% reduction in runtime without any structural modification to the codebase. B. Low-Complexity Restructuring: Static Dictionary Caching After removing runtime instrumentation overhead, the next optimization targeted the dominant computational bottleneck identified through profiling: repeated graph queries inside the dynamic Critical Path Method (CPM) calculation. The genetic programming hyper-heuristic simulator repeatedly evaluates candidate scheduling decisions by recomputing precedence relationships among unfinished activities. This dynamic CPM calculation is executed thousands of times during evolutionary search and therefore represents a performance-critical execu- tion pathway. The original implementation relied on the NetworkX [28] graph abstraction to retrieve predecessor and successor rela- tionships during each simulation step. Although NetworkX provides a convenient and flexible interface for graph manipu- lation, its dynamic graph views introduce substantial overhead 1. Establish a trusted benchmark Representative Large enough to expose scaling behaviour Repeatable Small enough for frequent execution Correctness guard Checksums + baseline runtime AI coding agent Driver 2. Run benchmark and profiler Collect runtime and call costs 3. Analyze profile Rank costs and identify the next hot spot 4. Propose and apply a scoped change Produce code diff and rationale Candidate revision Modified code, not yet accepted Programmer Navigator 5. Inspect the revision Review diff, assumptions, and maintainability 6. Verify independently Rerun checksums and re-measure runtime Correct and faster? 7. Human accepts change Commit and open pull request Accepted optimization iterations Performance target reached? Verified optimized code Yes No: reject or revise Yes No: re-profile updated code Fig. 5. Semi-automated, human-in-the-loop code-optimization workflow. The AI coding agent acts as the driver by executing the benchmark and profiler, identifying the next hot spot, and applying a scoped change. The programmer acts as the navigator by inspecting the revision, independently validating checksums and runtime, and retaining final authority over commits and pull requests. Accepted changes are re-profiled iteratively until the performance target is reached. when repeatedly accessed inside deeply nested simulation loops. Each query requires traversal through Python-level graph objects, including adjacency dictionaries wrapped by NetworkX view objects, dynamic attribute resolution, and iterator creation. Profiling identified these NetworkX operations as a signifi- cant contributor to runtime. In particular, operations such as: _subgraph.predecessors(cur_act) _subgraph.successors(cur_act) graph_nx.successors(task) were repeatedly executed during the forward and backward passes of the CPM calculation. Because the project dependency graph remains static throughout the simulation process, repeatedly querying the NetworkX representation provided no computational benefit. The graph topology does not change during genetic program- ming evaluation; only the scheduling state changes. a) Action: The optimization replaced dynamic Net- workX graph access with pre-computed native Python dic- tionary structures. During problem initialization, the graph topology was extracted into direct adjacency mappings: predecessors_dict[node] = predecessor_nodes neighbors_dict[node] = successor_nodes These structures were then accessed directly during simu- lation: pred_dict = self.rcpsp_problem.graph. predecessors_dict succ_dict = self.rcpsp_problem.graph. neighbors_dict The CPM forward pass was modified from dynamic Net- workX traversal: pred_acts = list(_subgraph.predecessors( cur_act)) to direct dictionary lookup: pred_acts = [ p for p in pred_dict.get(cur_act, set()) if p in subproblem_set ] Similarly, backward CPM propagation was changed from: succ_acts = list(_subgraph.successors(cur_act) ) to: succ_acts = [ s for s in succ_dict.get(cur_act, set()) if s in subproblem_set ] Additional restructuring included: replacing NetworkX sub- graph construction with direct set-based node filtering; avoid- ing repeated graph object creation; and replacing graph-size queries such as _subgraph.number_of_nodes() with direct collection size evaluation: len(_subproblem) preserving NetworkX only for offline graph construction and analysis rather than runtime simulation. The modification required limited code changes because the optimization preserved the original algorithmic logic. The CPM calculation, precedence constraints, and scheduling de- cisions remained unchanged; only the underlying graph access mechanism was replaced. b) Impact: This low-complexity restructuring reduced runtime by 273 seconds (4.5 minutes), representing approx- imately 30% performance improvement for the simulator execution workload. The improvement was achieved without changing the genetic programming representation, modifying heuristic operators, altering scheduling constraints, reducing simulation accuracy, or changing solution quality. Instead, the optimization removed unnecessary abstraction overhead by moving invariant graph processing from the simulation phase into the initialization phase. This result demonstrates an important performance engi- neering principle for scientific Python workloads: general- purpose data structures should not remain inside high- frequency computational kernels when their underlying in- formation is static. By replacing dynamic graph views with lightweight adjacency tables, the framework retained Net- workX’s usability during model construction while achieving significantly improved execution efficiency during large-scale evolutionary optimization. C. Algorithmic Restructuring: Incremental Resource Feasibil- ity Tracking After optimizing graph access and simulation-level over- head, profiling identified the feasibility checking routine (check_feasible) as another major runtime bottleneck. This routine is responsible for evaluating candidate activity combinations during the activity group selection process of the scheduling simulator. The original implementation used a branch-and-bound enu- meration strategy to identify feasible activity groups under resource constraints. At each node of the search tree, the algorithm considered extending the current partial solution by adding a new activity. Before accepting the extension, the feasibility checker recalculated the total resource consumption of the complete partial combination. For every candidate expansion, the original implementation performed a full ag- gregation operation: resource_consumed = np.sum( [ self.rcpsp_problem.mode_resources_matrix [comb[0]][comb[1]] for comb in new_combination ], axis=0, ) This required iterating through all previously selected ac- tivities in the current combination and summing their re- source requirements again, even though most of the resource consumption state remained unchanged between neighboring search-tree nodes. Because the branch-and-bound procedure explores a large number of candidate combinations, the same resource con- tributions were repeatedly recomputed across many related search states. The computational cost therefore grew unnec- essarily with the depth and breadth of the enumeration tree. a) Action: A structural algorithmic redesign was in- troduced by replacing full recomputation with incremental resource state propagation. Instead of deriving the resource usage from the complete activity combination at every search step, the current resource consumption vector was treated as part of the search state and propagated through the branch-and- bound tree. The revised implementation introduced a persistent resource tracking variable: resource_consumed which represents the accumulated resource demand of the current partial combination. When a new activity is considered, only the incremental resource contribution of that activity is calculated: new_resource_consumed = ( resource_consumed + self.rcpsp_problem.mode_resources_matrix[ new_item[0]][new_item[1]] ) Feasibility is then evaluated directly against the available resources: bool(np.all(current_resource_avail >= new_resource_consumed)) The search state stored in the priority queue was extended from: (priority, id, combination, remaining) to: (priority, id, combination, remaining, resource_consumed) This allowed each child node in the search tree to inherit the resource state of its parent and update only the newly introduced activity demand. b) Additional Structural Improvements: The optimiza- tion also reduced repeated computation by moving invariant operations outside the search loop. 1) Resource availability calculation moved outside feasibil- ity checking: Previously, each feasibility evaluation accessed self.resource_avail_in_time[:, self. current_time] inside the checking function. This was replaced with a single calculation before branch-and-bound expansion: current_resource_avail = ( self.resource_avail_in_time[:, self. current_time] ) Since resource availability does not change during a sin- gle activity-group selection procedure, repeated retrieval was unnecessary. 2) Initial resource state construction: The search tree was initialized with an empty resource vector: _zero_resources = np.zeros( self.rcpsp_problem.mode_resources_matrix[ eligibles[0][0] ][eligibles[0][1]].shape, dtype=float, ) The initial heap state was then extended: (0, max_id, [], list(eligibles), _zero_resources) allowing resource information to flow naturally through the search process. c) Impact: The incremental resource tracking architec- ture reduced execution time by 330 seconds (5.5 minutes) compared with the previous implementation. Unlike previ- ous optimizations that primarily removed software overhead, this improvement required an algorithmic restructuring of the search procedure. The optimization achieved performance gains by reducing unnecessary repeated computation while preserving the exact feasibility evaluation logic. The improve- ment provides several advantages: • Reduced computational complexity: resource feasibil- ity checks changed from repeated summation over partial solutions to constant-time incremental updates. • Improved scalability: deeper branch-and-bound explo- ration benefits more significantly because each additional search level avoids recomputing accumulated resource usage. • Preserved solution quality: the branch-and-bound search space and feasibility constraints remain un- changed. • Maintained deterministic behavior: candidate selection and scheduling decisions are identical before and after optimization. This optimization demonstrates an important principle in evolutionary scheduling systems: state information that evolves predictably during search should be maintained in- crementally rather than reconstructed repeatedly. By treating resource consumption as part of the search state, the simulator substantially reduced computational overhead within one of its most frequently executed decision-making components. D. Medium-Complexity Compilation: Accelerating Critical Scheduling Kernels with Numba JIT After addressing high-level architectural inefficiencies, the remaining performance bottlenecks were concentrated in com- putational kernels that performed repeated feasibility searches during schedule generation. One such hot spot was the earliestStart function, which determines the earliest feasible start time for an activity by scanning the available resource timeline. The earliestStart operation is executed extensively during simulation because every candidate scheduling decision requires evaluating whether an activity can be placed within the current resource constraints. For large resource-constrained project scheduling problems (RCPSP), this function may be invoked millions of times during genetic programming evalu- ation. The original implementation used a pure Python and NumPy-based approach: result = self.resource_avail_in_time - resource_req for t in range(from_time, result.shape[1] - duration + 1): if np.all(result[:, t:t+duration] >= 0): return t Although NumPy provides efficient vectorized operations, this implementation introduced several hidden costs when executed at high frequency: • Repeated temporary array allocation. The sub- traction operation resource_avail_in_time - resource_req generated a new intermediate array for every invocation. For millions of calls, these temporary allocations created significant memory traffic and garbage collection overhead. • Repeated slicing operations. Each candidate time win- dow required creation of a NumPy slice result[:, t:t+duration], which introduced additional indexing overhead. • Python-level iteration around vector operations. Al- though the inner comparison was performed by NumPy, the outer search loop remained controlled by Python. The repeated transition between Python execution and optimized NumPy routines limited performance gains. Profiling showed that this function represented a significant fraction of simulator execution time, making it an ideal can- didate for low-level compilation. a) Action: The earliestStart computation was re- designed as a compiled numerical kernel using Numba Just-In- Time (JIT) [32] compilation. A dedicated Numba-compatible implementation was introduced: @numba.njit(cache=True) def _earliest_start_nb( resource_avail: np.ndarray, resource_req: np.ndarray, from_time: int, duration: int, ) -> int: The function was rewritten using explicit loops over can- didate start times, activity duration windows, and resource dimensions. The search algorithm directly examines resource feasibility: for t in range(from_time, end): ok = True for s in range(t, t + duration): for r in range(n_resources): if resource_avail[r, s] < resource_req[r]: ok = False break This design enables LLVM-based compilation by Numba because all operations operate on primitive integer values, contiguous NumPy arrays, and statically typed numerical oper- ations. The original object-heavy implementation was replaced with a lightweight numerical kernel. b) Runtime Optimization Strategies: The compiled im- plementation introduced several additional improvements. 1) Elimination of temporary array creation: Instead of com- puting resource_avail - resource_req for every invocation, the kernel directly compares resource availability: resource_avail[r, s] < resource_req[r] This avoids allocating intermediate arrays. For workloads containing millions of scheduling evaluations, avoiding these allocations significantly reduces memory movement and inter- preter overhead. 2) Early termination during infeasible checks: The original implementation evaluated complete NumPy expressions before determining feasibility. The Numba kernel introduces early exit behaviour: if resource_avail[r, s] < resource_req[r]: ok = False break As soon as a single resource constraint violation is iden- tified, the remaining checks for that candidate window are skipped. This is particularly effective because many candidate scheduling positions are infeasible and can be rejected early. 3) Removal of Python interpreter overhead: The com- piled function executes the nested search loops as optimized machine code through LLVM. This eliminates Python loop interpretation, repeated function dispatch, NumPy temporary object management, and dynamic type checking. The Python- facing simulator now only performs the initial data preparation and receives the computed start time: t = _earliest_start_nb( self.resource_avail_in_time, resource_req, from_time, duration, ) c) Impact: The Numba-based compilation reduced total runtime by 184 seconds (approximately 3 minutes) compared with the previous optimized implementation. The improve- ment was achieved with medium implementation complex- ity because the optimization required identifying a suitable numerical hot spot, separating the computational kernel from object-oriented simulator code, converting data structures into Numba-compatible NumPy arrays, and replacing high-level vector operations with explicit compiled loops. However, the scheduling algorithm itself remained unchanged. The opti- mization preserved identical resource feasibility constraints, identical earliest start decisions, and identical generated sched- ules. The improvement demonstrates that carefully selected JIT compilation can provide substantial performance benefits for scientific Python applications without requiring migration to a lower-level programming language. V. EVALUATION & FINANCIAL IMPACT The combined application of these architectural refactoring tiers was tested across production datasets on the REANNZ HPC network infrastructure. Fig. 6 summarizes the runtime savings, implementation effort, and primary system benefit of each optimization layer. Optimization Layer Time Saved EffortPrimary Benefit Debugflag overhaul (-O) 511 sMinimal Eradication of logging & assertion overhead Pre-built dictover NetworkX views 273 sLowEliminationof dynamiclibrary lookups Incremental resource tracking 330 sHighAsymptotic reduction in calculation loops Numba-JIT earliestStart 184 sMedium Native loop compila- tion via LLVM prim- itives Fig. 6. Summary of Optimization Layers and Their Impact: Runtime reduction achieved by the four optimization layers, from the legacy baseline (1298 seconds, 5.17M compute units/yr) to the optimized implementation (195 seconds, 1.05M compute units/yr). The cumulative impact of the refactoring pipeline dropped total simulation time from a non-optimized benchmark of 1,298 seconds to 195 seconds, an 85% execution compute time saved on the HPC. Fig. 6 illustrates the cumulative effect of each optimization layer on total runtime and annual compute unit consumption. Prior to this consultancy, the project’s historical footprint of ̃5,173,000 compute units violated the allocated ceiling. By compressing execution cycles, the optimized code now fits comfortably within the newly approved 1,054,000 compute unit quota. The refactored framework saves over 4 million compute units (equivalent to CPU core-hours) per year, which translates into an annual reduction of NZ $320,000 (approxi- mately US $188,000) in compute costs. VI. CONCLUSIONS This work demonstrates a practical AI-assisted workflow that treats scientific code optimization as a continuous and evidence-driven process. Agentic AI can help researchers identify performance bottlenecks, propose and evaluate im- provements, and provide explanations for code changes. This makes performance engineering more accessible to domain researchers with limited specialist software-engineering exper- tise, while human review preserves scientific correctness and control over the codebase. The workflow has potential applications beyond the project- scheduling problem studied here, particularly for simulation- intensive scheduling and other experiment-intensive research domains. Applying this approach to performance-limited re- search software could improve HPC resource efficiency, re- duce computational costs, and accelerate scientific discovery. Future work will investigate its application across a broader range of research projects where software performance limits experimental scale and productivity. REFERENCES [1] C. R. Harris, K. J. Millman, S. J. van der Walt, R. Gommers, P. Virtanen et al., “Array programming with NumPy,” Nature, vol. 585, p. 357–362, 2020. [Online]. Available: https://doi.org/10.1038/s41586-020-2649-2 [2] A. Paszke, S. Gross, S. Chintala, G. Chanan, E. Yang, Z. DeVito, Z. Lin, A. Desmaison, L. Antiga, and A. Lerer, “Automatic differentiation in pytorch,” in NIPS-W, 2017. [Online]. Available: https://openreview.net/ pdf/25b8e6c373d48b84e5e9c6e10e7cbbbce4ac73.pdf [3] G. Wilson, J. Bryan, K. Cranston, J. Kitzes, L. Nederbragt, and T. K. Teal, “Good enough practices in scientific computing,” PLOS Computational Biology, vol. 13, no. 6, p. e1005510, 2017. [Online]. Available: https://doi.org/10.1371/journal.pcbi.1005510 [4] Anthropic, “Enabling Claude Code to work more autonomously,” Sep. 2025, accessed: 2026-08-04. [Online]. Available: https://w.anthropic. com/news/enabling-claude-code-to-work-more-autonomously [5] OpenAI,“Codexisnowgenerallyavailable,”Oct.2025, accessed: 2026-08-04. [Online]. Available: https://openai.com/index/ codex-now-generally-available/ [6] A. Sarkar and I. Drosos, “Vibe coding: Programming through con- versation with artificial intelligence,” arXiv preprint arXiv:2506.23253, 2025. [Online]. Available: https://doi.org/10.48550/arXiv.2506.23253 [7] V. Schmid, “Solving the dynamic ambulance relocation and dispatching problem using approximate dynamic programming,” European Journal of Operational Research, vol. 219, no. 3, p. 611–621, 2012. [Online]. Available: https://doi.org/10.1016/j.ejor.2011.10.043 [8] J. MacLachlan, Y. Mei, F. Zhang, and M. Zhang, “Genetic programming for vehicle subset selection in ambulance dispatching,” in 2022 IEEE Congress on Evolutionary Computation (CEC).IEEE, 2022, p. 1–8. [Online]. Available: https://doi.org/10.1109/CEC55065.2022.9870323 [9] J. MacLachlan, Y. Mei, F. Zhang, M. Zhang, and J. Signal, “Learning emergency medical dispatch policies via genetic programming,” in Proceedings of the Genetic and Evolutionary Computation Conference. New York, NY, USA: Association for Computing Machinery, 2023, p. 1409–1417. [Online]. Available: https://doi.org/10.1145/3583131. 3590434 [10] J. P. Pell, J. M. Sirel, A. K. Marsden, I. Ford, and S. M. Cobbe, “Effect of reducing ambulance response times on deaths from out of hospital cardiac arrest: Cohort study,” BMJ, vol. 322, no. 7299, p. 1385–1388, 2001. [Online]. Available: https://doi.org/10.1136/bmj.322.7299.1385 [11] P. J. H. Hulshof, N. Kortbeek, R. J. Boucherie, E. W. Hans, and P. J. M. Bakker, “Taxonomic classification of planning decisions in health care: A structured review of the state of the art in OR/MS,” Health Systems, vol. 1, no. 2, p. 129–175, 2012. [Online]. Available: https://doi.org/10.1057/hs.2012.18 [12] A. Zhao, P. Liu, X. Gao, G. Huang, X. Yang, Y. Ma, Z. Xie, and Y. Li, “Data-mining-based real-time optimization of the job shop scheduling problem,” Mathematics, vol. 10, no. 23, p. 4608, 2022. [Online]. Available: https://doi.org/10.3390/math10234608 [13] X. Lu, K. Zhou, X. Zhang, and S. Yang, “A systematic review of supply and demand side optimal load scheduling in a smart grid environment,” Journal of Cleaner Production, vol. 203, p. 757–768, 2018. [Online]. Available: https://doi.org/10.1016/j.jclepro.2018.08.301 [14] S. E. Christodoulou, E. S. Tezias, and K. A. Galaras, “Resource- constrained scheduling of construction projects and simulation of the entropy impact on a project’s duration and cost,” International Journal of Project Organisation and Management, vol. 4, no. 4, p. 322–338, 2012. [Online]. Available: https://doi.org/10.1504/IJPOM.2012.050328 [15] S. Hartmann and D. Briskorn, “An updated survey of variants and extensions of the resource-constrained project scheduling problem,” European Journal of Operational Research, vol. 297, no. 1, p. 1–14, 2022. [Online]. Available: https://doi.org/10.1016/j.ejor.2021.05.004 [16] H. F. Rahman, R. K. Chakrabortty, S. Elsawah, and M. J. Ryan, “Energy- efficient project scheduling with supplier selection in manufacturing projects,” Expert Systems with Applications, vol. 193, p. 116446, 2022. [Online]. Available: https://doi.org/10.1016/j.eswa.2021.116446 [17] M. Asadujjaman, H. F. Rahman, R. K. Chakrabortty, and M. J. Ryan, “Supply chain integrated resource-constrained multi-project scheduling problem,” Computers & Industrial Engineering, vol. 194, p. 110380, 2024. [Online]. Available: https://doi.org/10.1016/j.cie.2024.110380 [18] P. A. Kurt and B. Kececi, “Resource constrained multi-project scheduling: Application in software company,” in Advances in Manufacturing, Production Management and Process Control. Cham: Springer International Publishing, 2018, p. 549–557. [Online]. Available: https://doi.org/10.1007/978-3-319-94196-7 51 [19] G. Chen, W. He, Y. Tian, and K. Ma, “Resource-constrained project scheduling with multiple states: Bi-objective optimization model and case study of aircraft maintenance,” Computers & Industrial Engineering, vol. 191, p. 110169, 2024. [Online]. Available: https://doi.org/10.1016/j.cie.2024.110169 [20] J. Bła ̇ zewicz, J. K. Lenstra, and A. H. G. Rinnooy Kan, “Scheduling subject to resource constraints: Classification and complexity,” Discrete Applied Mathematics, vol. 5, no. 1, p. 11–24, 1983. [Online]. Available: https://doi.org/10.1016/0166-218X(83)90012-4 [21] M. Bold and M. Goerigk, “A faster exact method for solving the robust multi-mode resource-constrained project scheduling problem,” Operations Research Letters, vol. 50, no. 5, p. 581–587, 2022, preprint: arXiv:2203.06983. [Online]. Available: https://doi.org/10. 1016/j.orl.2022.08.003 [22] S. Hartmann, “A competitive genetic algorithm for resource-constrained project scheduling,” Naval Research Logistics, vol. 45, no. 7, p. 733–750, 1998. [Online]. Available: https://doi.org/10.1002/(SICI) 1520-6750(199810)45:7⟨733::AID-NAV5⟩3.0.CO;2-C [23] V. Valls, F. Ballest ́ ın, and S. Quintanilla, “A hybrid genetic algorithm for the resource-constrained project scheduling problem,” European Journal of Operational Research, vol. 185, no. 2, p. 495–508, 2008. [Online]. Available: https://doi.org/10.1016/j.ejor.2006.12.033 [24] S. Nguyen, Y. Mei, and M. Zhang, “Genetic programming for production scheduling: A survey with a unified framework,” Complex & Intelligent Systems, vol. 3, no. 1, p. 41–66, Mar. 2017. [Online]. Available: https://doi.org/10.1007/s40747-017-0036-x [25] F. Zhang, Y. Mei, S. Nguyen, and M. Zhang, “Survey on Genetic Programming and Machine Learning Techniques for Heuristic Design in Job Shop Scheduling,” IEEE Transactions on Evolutionary Computation, vol. 28, no. 1, p. 147–167, 2024. [Online]. Available: https://doi.org/10.1109/TEVC.2023.3255246 [26] S. Amaran, N. V. Sahinidis, B. Sharda, and S. J. Bury, “Simulation optimization: A review of algorithms and applications,” Annals of Operations Research, vol. 240, no. 1, p. 351–380, 2016. [Online]. Available: https://doi.org/10.1007/s10479-015-2019-x [27] The pandas development team, “pandas-dev/pandas: Pandas,” Feb. 2020. [Online]. Available: https://doi.org/10.5281/zenodo.3509134 [28] A. A. Hagberg, D. A. Schult, and P. J. Swart, “Exploring network structure, dynamics, and function using networkx,” Python in Science Conference, 2008. [Online]. Available: https://doi.org/10. 25080/TCWV9851 [29] Q. Zhang, L. Xu, X. Zhang, and B. Xu, “Quantifying the interpretation overhead of python,” Science of Computer Programming, vol. 215, p. 102759, 2022. [Online]. Available: https://doi.org/10.1016/j.scico.2021. 102759 [30] R. M. Fujimoto, “Research challenges in parallel and distributed simulation,” ACM Transactions on Modeling and Computer Simulation, vol. 26, no. 4, p. 1–29, 2016. [Online]. Available: https://doi.org/10. 1145/2866577 [31] W. Tang and Y. Yao, “A GPU-based discrete event simulation kernel,” SIMULATION, vol. 89, no. 11, p. 1335–1354, 2013. [Online]. Available: https://doi.org/10.1177/0037549713508839 [32] S. K. Lam, A. Pitrou, and S. Seibert, “Numba: A LLVM-based Python JIT compiler,” in Proceedings of the Second Workshop on the LLVM Compiler Infrastructure in HPC, ser. LLVM ’15.New York, NY, USA: Association for Computing Machinery, Nov. 2015, p. 1–6. [Online]. Available: https://doi.org/10.1145/2833157.2833162 [33] V. Van Peteghem and M. Vanhoucke, “An experimental investigation of metaheuristics for the multi-mode resource-constrained project scheduling problem on new dataset instances,” European Journal of Operational Research, vol. 235, no. 1, p. 62–72, 2014. [Online]. Available: https://doi.org/10.1016/j.ejor.2013.10.012 [34] Y. Tian, Y. Mei, and M. Zhang, “Scalable knee-point guided activity group selection in multi-tree genetic programming for dynamic multi-mode project scheduling,” in PRICAI 2025: Trends in Artificial Intelligence, Y. Mei, C. Qian, Q. Bai, B. Xue, and S. Khanna, Eds. Singapore: Springer Nature Singapore, 2026, vol. 16454, p. 576–592. [Online]. Available: https://doi.org/10.1007/978-981-95-7081-240 [35] K. Beck, Extreme Programming Explained: Embrace Change. Reading, MA: Addison-Wesley, 2000. [Online]. Available: https://books.google. com/books?id=G8EL4H4vf7UC [36] L. Williams, R. R. Kessler, W. Cunningham, and R. Jeffries, “Strengthening the case for pair programming,” IEEE Software, vol. 17, no. 4, p. 19–25, 2000. [Online]. Available: https: //doi.org/10.1109/52.854064