Abstract

Agent-Based Modelling (ABM) tools provide a cost-effective way to simulate complex systems like an Internet of Things Distributed Ledger Technology (IoT-DLT) networks, where nodes operate as autonomous agents. While physical testbeds are expensive, ABMs offer scalable and efficient alternatives. However, few studies compare ABM performance on standard consumer hardware. In this research, we evaluate NetLogo 6.3 and Agents.jl (Julia 1.9) by simulating an IoT-DLT model across two laptop configurations. Results show that Agents.jl runs up to 9× faster on newer hardware and 4× faster on older hardware compared to NetLogo, though it requires more setup. NetLogo remains user-friendly but underutilises system resources like GPU and multicore processing. The research uses inferential analysis tools, such as regression analysis, to rigorously evaluate the performance differences between the ABM tools and hardware configurations. This research helps researchers choose efficient ABM tools for large-scale simulations on personal computers, demonstrating that emerging tools like Agents.jl are promising candidates for future simulations.

1. Introduction

Complex systems consist of interacting individual components that exhibit emergent global behaviour. Multi-Agent Systems (MAS) are widely used to model such systems, simulating real-world interactions where agents operate autonomously and engage in social behaviour like cooperation and negotiation ¹. Agent-Based Modelling (ABM) has emerged as a key tool for empirical research, enabling "bottom-up" analysis of complex systems ². In ABM, agents follow predefined rules, and their collective interactions reveal emergent properties, making ABM particularly valuable for studying Internet of Things with Distributed Ledger Technology (IoT-DLT) networks, where scalability and cost pose challenges for physical testbeds ³ and ⁴.

While ABM tools like NetLogo offer abstraction layers for model development, their performance on standard hardware remains understudied. Efficient resource utilisation, such as multicore/GPU support, can significantly reduce simulation time and costs. This research addresses this gap by comparing two ABM tools: NetLogo 6.3 (a user-friendly, established platform) and Agents.jl (Julia 1.9) (a high-performance alternative touted for scalability). This study evaluates these tools using an IoT-DLT simulation, ported from NetLogo to Agents.jl, with the following goals:

• Evaluate temporal Performance measurement: Comparison of mean simulation times across different network sizes.

• Perform a temporal runtime difference between each ABM tool on different generations of laptops.

• Identify the trade-off between performance and non-performance strengths and limitations of each ABM tool.

• Measure speed-up and show how modern tools like Agents.jl can outperform traditional ABMs in efficiency.

This research provides a practical framework for selecting ABM tools when modelling transaction-intensive, multi-agent systems like IoT-DLT networks, using the IoT-Direct Acyclic Graph-Based Distributed Ledger Technology Simulation (IoT-DAG-DLTSim) model as a benchmark case. By establishing performance baselines that demonstrate execution speed differences between NetLogo and Agents.jl across hardware generations, the study offers empirically validated criteria for tool selection.

The research also presents a refined experimental approach, which included rerunning the simulations to ensure robustness. Furthermore, this work incorporates inferential statistical analysis and specifically regression modelling to provide a rigorous and statistically validated understanding of the factors influencing simulation performance, such as the choice of ABM tool, hardware configuration, and simulation scale.

The research develops a decision matrix comparing computational efficiency, development complexity, and hardware utilisation capabilities specifically for simulations requiring high transaction throughput and concurrent agent interactions. Furthermore, it validates how emerging ABM architectures (Agents.jl) overcome scalability limitations of traditional platforms (NetLogo) in large-scale IoT-DLT scenarios, providing researchers with both quantitative metrics and qualitative evaluation guidelines for tool adoption.

The rest of the paper is structured as follows: Section 2 reviews related work; Section 3 details the materials and methods; Section 4 presents the results obtained; Section 5 discusses implications of the results; and Section 6 concludes with a summary of the work and future directions for IoT-DAG-DLT scalability performance research.

Recent research has emphasised the growing role of Agent-Based Modelling (ABM) tools in simulating complex systems, particularly for domains like IoT and distributed ledgers. Surveys by ^{5, 6} and ⁷ provide overviews of widely used ABM frameworks and their applicability in various research domains. These reviews collectively highlight tools such as NetLogo ⁸, MASON ⁹, Mesa ¹⁰, FLAME GPU ¹¹, and the more recent Agents.jl ¹², each offering trade-offs between usability, flexibility, and performance.

Several studies have attempted to benchmark the computational performance of ABM platforms, especially when simulating models with high agent counts or requiring intensive concurrent interactions. For instance, in ¹¹, the authors introduce FLAME GPU 2, a high-performance ABM framework written in C++ with GPU acceleration capabilities. Their work demonstrates how parallel execution and minimised data movement can achieve simulation speedups of up to 10× compared to traditional GPU baselines. However, such tools often require specialised hardware (e.g., NVIDIA V100 GPUs) and expertise in parallel programming, limiting accessibility for researchers using standard laptops or desktops.

The ABM tool Agents.jl, developed in Julia, has emerged as a performant and flexible alternative for ABM development. In ¹², the authors compare Agents.jl to NetLogo, Mesa, and MASON across a suite of well-known ABM benchmarks, such as Flocking and Schelling. The study evaluates both runtime performance and development effort, showing that Agents.jl delivers competitive performance with significantly fewer lines of code, making it suitable for large-scale simulations on modern CPUs. However, their analysis does not explore performance variability across different hardware generations.

The ABM tool NetLogo, by contrast, remains a widely adopted ABM platform due to its low barrier to entry and integrated modelling environment. Its strengths lie in accessibility and ease of use, particularly for education and early-stage prototyping ⁹. Yet, several studies (e.g., ^{11, 12}) have noted its limitations in utilising multicore processors or GPUs, which can restrict its scalability for computation-heavy simulations like those seen in IoT-DLT networks.

MASON, as discussed in ⁹, offers extensibility and modular design through its Java-based architecture. It separates model logic from visualisation, facilitating headless simulations and batch runs. Though it performs better than NetLogo in some benchmarks, MASON still falls short of tools like FLAME GPU or Agents.jl in terms of raw speed, especially for large-scale agent interactions.

While these works offer valuable comparisons across frameworks, few have examined how ABM tools perform on everyday consumer-grade hardware, an increasingly relevant consideration for researchers without access to high-performance computing resources. This study addresses this gap by benchmarking NetLogo and Agents.jl using the same IoT-DLT simulation model across two common laptop configurations, quantifying runtime differences and identifying practical trade-offs in tool adoption for real-world deployment contexts.

In this research, an experiment was performed by running simulations of the IoT-DAG-DLTSim model on two different multicore/GPU laptops, hosted on a multithreaded, multicore operating system. The model was designed to study the effect of horizontal scalability on IoT-DAG-DLTSim, and the effect of using different algorithms to attach light IoTs, which are not capable of storing their own distributed ledger database to full nodes. The results of the simulation were collected using CSV files and analysed to provide the required results based on the objectives.

2. Methods and Materials

In this research, an experiment was performed by running simulations of the IoT-DAG-DLTSim model on two different multicore/GPU laptops, hosted on a multithreaded, multicore operating system. The model was designed to study the effect of horizontal scalability on IoT-DAG-DLTSim, and the effect of using different algorithms to attach light IoTs, which are not capable of storing their own distributed ledger database to full nodes. The results of the simulation were collected using CSV files and analysed to provide the required results based on the objectives.

The IoT-DAG-DLTSim model was designed using the Agent Unified Modelling Language (A-UML) approach and implemented using two tools: NetLogo 6.3, an ABM based on Java Virtual Machine (JVM), and Agents.jl Julia 1.9, an ABM based on Low-Level Virtual Machine (LLVM). Model performance was measured and focused on IoT device scalability, transaction throughput, latency, and model completion times.

The IoT-DAG-DLTSim ecosystem design is shown in Figure 1(a) includes a set of Agents, , some having active ledgers, others with no ledger, and the Agents connect to each other via the network. This is depicted as a three-layer model, Figure 1(a), as shown, and includes random network internet connections between agents. Individual agents were designed to use a gossip-like protocol to receive, process, and send messages. Transaction processing involved handling new data and replication requests, local processing, and gossiping information to neighbours.

During each epoch, 0.1% of the Agents randomly produced transactions. Agents receive or generate transactions and update their local database. A Gossip SIR ¹³ protocol is employed to propagate these transactions to neighbouring agents. New transactions are added to the Direct Acyclic Graph (DAG) Ledger database as new tips by attaching them to two existing tips in the local database. The transactions are then gossiped using the Gossip SIR algorithm to neighbouring agents for replication. When transactions for replication are received, the DAG Ledger attaches them to the corresponding DAG tips, if they have been received. If not received, the DAG Ledger waits for the required tips. If waiting takes too long, agents request the missing DAG transactions from neighbours using a Gossip SIR-like algorithm.

The key components of the agent model are:

• Agents: Classified as Full-agents (with a local DAG-Ledger database) or light-agents (with no DAG-Ledger database).

• Agent network: Agents are interconnected using a scale-free random network. This uses the Barabasi and Albert Preferential Attachment (PA) algorithm ¹⁴, simulating internet-like connections with a k-degree of 2.3, based on empirical data.

• DAG Ledger: Each agent maintains a local database to store new transactions and replicate neighbours' transactions. The DAG Ledger is built using an IOTA Tangle ¹⁵ like random algorithm.

• Gossip Protocol: Agents send and receive messages using the random Gossip SIR model. This protocol performs a push for new messages and a pull for any missing DAG tips based on the age of the updates.

The Figure 1(c) shows the impact of the percolation of the DAG Ledger transactions over time, starting as database (DB) tips, then intermediary tips as the databases became synchronised with each other. The final stage is reached when ¾ of the DAG-Ledger DB sites have received the same transaction tips, this achieves the required Byzantine Fault Tolerance to allow a transaction to be deemed confirmed ¹⁶.

The Table 1, shows the parameters used to set-up and run the experiment. The input parameters determine the size of the PA network, which changes during successive experiments in order to simulate horizontal scalability. The remaining inputs remain the same. There are various output parameters which can be configured. For this experiment, only the time taken to set up and run the experiment is used.

The mean simulation time was measured over 30 runs of the model, each running for 1000 time epochs. These experiments were conducted on two machines, with hardware specifications detailed in Table 2. The Figure 2 presents a high-level pseudocode illustrating the model design. It includes two main routines: “Pseudo Code 1 Setup”, initialising and setting up the simulation, and “Pseudo Code 2 Run Experiment” shows the behaviour of each full node, which involves receiving data, processing and storing it in the DAG-based DLT, and broadcasting transactions to neighbouring agents via a gossip protocol. The IoT agent network topology was generated using the Preferential Attachment (PA) algorithm from ¹⁷, with a degree parameter , which approximates real-world internet router connectivity patterns.

In Figure 2, represent the experiment run being executed, represents the total number of nodes simulated, is how the full agents interconnection topology, is the time sequence, is the agent, is the probability of an agent generating a new transaction, is the received transaction that need to be attached to the local DAG Ledger, either new or replication.

NetLogo 6.3 comes with a Graphical User Interface (GUI) and a behaviour module that allows you to set up experiments, their input parameters, and the output parameters. Figure 3(a) shows the standard GUI of NetLogo tool and the designed interface, while Figure 3(b), shows the tool used to configure and run the experiments and perform parameter iterations.

Note that only the number of agents where changed i.e. 100 to 6400 for each experiment, and the experiment was repeated 30 times. The data was exported from the experiment using the NetLogo CSV extension ¹⁸, and the data loaded into Julia 1.9 using CSV,jl and analysed using the Julia 1.9 DataFrames.jl ¹⁹, StatsBase.jl ²⁰, HypothesisTesting.jl ²¹, GLM.jl ²², Plots.jl ²³, CurveFit.jl ²⁴ package libraries to generate the descriptive, inferential and visualisations.

During development, the IoT-DAG-DLTSim application was tuned using the data profiling tools available as an extension in Julia. This allowed for the selection of improved techniques to improve the performance ²⁵. The JupyterLab was used for the data analysis to allow documentation of the data collection and analysis process.

Agents.jl Julia ABM does include a default GUI and users manage the tool via VS Code IDE or the native Julia command prompt (see Figure 4). A JupyterLab ²⁶ interface is also available. Julia offers a REPL (read, evaluate, print, loop), allowing users to input commands and see the results displayed immediately. The model interaction can be invoked using either the Makie.jl, WGLMakie.jl or GLMakie.jl ²⁷ libraries. These libraries allow for image, video capture or custom GUI interactions. In this experiment, the Agent.jl GUI was not used during experimental runs, opting for non-interactive mode to improve performance. However, the GUI graphics were utilised extensively in creating visualisations, providing user-selectable high-quality outputs in PNG(Portable Network Graphics), SVG(Scalable Vector Graphics), and PDF (Portable Document Format) file formats.

The data was loaded into Julia 1.9 DataFrames.jl ¹⁹, StatsBase.jl ²⁰, HypothesisTesting.jl ²¹, GLM.jl ²², Plots.jl ²³, CurveFit.jl ²⁴ package libraries to generate the descriptive, inferential and visualisations. The JupyterLab Notebook Interface was used for the data analysis, to allow documentation of the data collection and analysis process. During development, the Profiling.jl ²⁸ Julia Package was used to improve performance and reduce bottlenecks. The JupyterLab ²⁶ tool was used for the data analysis to allow documentation of the data collection and analysis process.

For each experiment, a CSV file was generated, and the results of each experiment run was appended to the file. The data was extracted from the Global-DAG-DLT database stored in a Julia Dictionary in the Agents.jl Julia 1.9 ABM and from table structure in NetLogo. The data was then analysed using the tools described in section 0 and 0. The results were stored in a results folder and used in the results section of this document.

Descriptive statistics, including mean simulation times and speed-up ratios, were initially calculated to summarise the performance results across varying agent counts and hardware configurations.

To provide a deeper, statistically robust evaluation of the factors affecting simulation performance, inferential statistical analysis was performed using regression modelling. The data collected from the 1680 experimental runs were analysed using the Julia 1.9 ecosystem, leveraging libraries such as DataFrames.jl, StatsBase.jl, HypothesisTesting.jl, and GLM.jl (Generalized Linear Models). Two regression models were constructed: one to predict the “setup_time” and another to predict the “exp_time” (experiment execution time). The predictor variables in these models included the ABM tool (NetLogo or Julia Agents.jl), the machine (TOi3 or HPi5), the nodes (number of agents), and the total number of transactions simulated. The regression analysis allowed for the identification of the statistical significance and magnitude of the effects of factors on the measured time metrics.

3. Results

The data collected was analysed using descriptive, inferential statistics and visualisation. For each of the models implemented using the two ABM tools and on the two hardware configurations, the results were compared for performance speed-up. In computer science, speed-up [29, p. 6] is measured by taking the base speed and dividing it by the speed of the item being measured, as shown in Equation (1). A positive value greater than one (>1) shows an improvement in performance, while a value of less than one shows a negative speed-up (slower). In our case, Speed-up is defined in terms of the work, while the time is kept constant.

(1)

Each model was run 30 times for varying network sizes of 100, 200, 400, 800, 1600, 3200 and 6400 IoT agents but with a fixed PA topology of K-degree = 2.3. In this experiment, all other parameters were kept constant i.e. . A total of x30 runs, for x7 Agent configurations, for x2 computing equipment, for x2 languages were formed creating a total of 1680 data samples.

The two models implemented on Julia ABM abbreviated as (JL) and NetLogo ABM abbreviated as (NL) in the table and are run on two different computer platforms TOi3 and HPi5. The Figure 5(a) shows the number of agents for each experiment set and the various combinations. The Figure 5 (b) shows the number of agents, both full nodes and light nodes. The Figure 5(b) shows the transaction arrival rate produced by the agents, the simulated transaction arrival rate per epoch, the replications per epoch that occurs per full agent, the Confirmed Transaction per second (CTPS) and the mean transaction latency (MTL) before 2/3 nodes have received the transactions.

The Figure 6 shows a visual representation of the seven (7) PA topologies used in the experiment to interconnect the agents. To allow for a fair comparison, the same PA configuration was used when performing each experiment with the same number of Agents.

In the following sections, we start by presenting the results of different ABMs on the same hardware. Finally, we calculate the overall speedup for performing the entire experiment by comparing the speed-up across different hardware and tools.

This section shows the performance comparison of the two ABMs and the relative speedup using different equipment.

The Table 3 shows the setup performance between NetLogo and Julia and the resultant speed-up when running the IoT-DAG-DLTSim on TOi3 configuration. The Table 4 shows the results of executing the experiment simulation and the resulting speed-up when running the IoT-DAG-DLTSim on TOi3 configuration. The Figure 7 plots the visualisation of the speed-up by performing a linear and non-linear regression fit against the results in Table 3 and Table 4.

The Table 4 shows the results of executing the experiment simulation and the resulting speed-up when running the IoT-DAG-DLTSim on TOi3 configuration. The Figure 7 plots the visualisation of the speed-up by performing a linear and non-linear regression fit against the results in Table 3 and Table 4.

The Figure 8 shows the calculated estimated linear and non-linear regression fit for the results in Table 3 and Table 4.

The results of Table 3, Table 4and Table 5 are plotted in Figure 7 to visualise the results and the curve fitted to evaluate their trend and predict their behaviour.

The Table 6 shows the setup performance between NetLogo and Julia and the resultant speed-up when running the IoT-DAG-DLTSim on HPi5 configuration. The Table 7 shows the results of executing the experiment simulation and the resulting speed-up when running the IoT-DAG-DLTSim on HPi5 configuration. The Table 8 shows the calculated estimated linear and non-linear regression fit for the results in Table 6 and Table 7. The Figure 8 plots the visualisation of the speed-up by performing a linear and non-linear regression fit for the results in Table 6, Table 7 and Table 8.

The results of running the full experiment on different hardware configurations were collected and the results presented in table and visual formats. The Table 9 shows the results of running the experiment using NetLogo and Julia on Toi3 configuration.

The Table 10 shows the results of running the experiment using NetLogo and Julia on HPi5 configuration.

The results of Table 9 and Table 10 are visualised in Figure 9 along with speed-up calculation between the ABM tools.

In this section, a regression analysis was performed on the setup and the experiment run. To complement the descriptive performance metrics and speed-up analysis, a rigorous inferential analysis was conducted using linear regression models to statistically evaluate the impact of the ABM tool, hardware, node count, and transaction count on simulation setup and execution times. Table 11 presents the regression results for the “setup time” model, while Table 12 presents the regression results for the “exp_time” model.

The interpretation of the regression results of Table 11 is as follows:

• Intercept: The intercept (-0.344 for setup time and -359.092 for execution time) represents the baseline when the tool is Julia and the machine is HPi5, with 0 nodes and 0 transactions. The negative intercepts indicate slightly negative baseline values for both setup time and execution time.

• Tool: NetLogo: For setup time, using NetLogo results in a 0.230 unit increase compared to the reference category, Julia, but this effect is not statistically significant (p-value = 0.527). For execution time, using NetLogo leads to a significant increase (342.122 units) compared to Julia, with a very small p-value (< 1e-32), indicating a robust effect.

• Machine: TOi3: In both models, using TOi3 increases the respective times compared to HPi5. The effect is modest for setup time (0.301 units) and large for execution time (161.161 units), with both coefficients being statistically significant.

• Nodes: For both setup time and execution time, the number of nodes has a negative effect, meaning that as the number of nodes increases, the times tend to decrease. This effect is statistically significant for execution time (p-value < 1e-04), but not for setup time (p-value = 0.103).

• Transactions: Each additional transaction increases setup time slightly (0.002 units), though only marginally significant for setup time (p-value = 0.0875), and increases execution time significantly (0.434 units, p-value 1e-05).

The interpretation of the regression results of Table 11 is as follows:

• Intercept: The intercept (-0.344 for setup time and -359.092 for execution time) represents the baseline when the tool is Julia and the machine is HPi5, with 0 nodes and 0 transactions. The negative intercepts indicate slightly negative baseline values for both setup time and execution time.

• Tool: NetLogo: For setup time, using NetLogo results in a 0.230 unit increase compared to the reference category, Julia, but this effect is not statistically significant (p-value = 0.527). For execution time, using NetLogo leads to a significant increase (342.122 units) compared to Julia, with a very small p-value (< 1e-32), indicating a robust effect.

• Machine: TOi3: In both models, using TOi3 increases the respective times compared to HPi5. The effect is modest for setup time (0.301 units) and large for execution time (161.161 units), with both coefficients being statistically significant.

• Nodes: For both setup time and execution time, the number of nodes has a negative effect, meaning that as the number of nodes increases, the times tend to decrease. This effect is statistically significant for execution time (p-value < 1e-04), but not for setup time (p-value = 0.103).

• Transactions: Each additional transaction increases setup time slightly (0.002 units), though only marginally significant for setup time (p-value = 0.0875), and increases execution time significantly (0.434 units, p-value 1e-05).

The Table 12 shows the results for the “exp_time” model. Each result includes the estimated coefficients, standard errors, t-values, and p-values for each predictor variable, indicating their statistical significance.

The interpretation of the regression results in Table 12 is as follows:

• Intercept (-359.092): The intercept represents the baseline execution time when the tool is Julia and the machine is HPi5, which are the reference categories. The negative value of the intercept indicates that, for the baseline categories, the execution time is negative (perhaps suggesting a computational anomaly or non-standard baseline, which could warrant further investigation).

• Tool: NetLogo (342.122): This coefficient reflects the change in execution time when using NetLogo instead of Julia. The large positive value (342.122) indicates that using NetLogo results in a significant increase in execution time compared to Julia.

• Machine: TOi3 (161.161): This coefficient shows the change in execution time when using TOi3 instead of HPi5. A positive value of 161.161 indicates that using TOi3 increases the execution time compared to HPi5.

• Nodes (-4.151): This negative coefficient indicates that as the number of nodes increases, the execution time decreases, which is statistically significant (p-value < 0.001).

• Transactions (0.434): For each additional transaction, the execution time increases by 0.434 units. This effect is statistically significant (p-value < 1e-05).

4. Discussion

In this section, the results are discussed, and inferences and implications are drawn from the results produced.

The speed-up analysis of Table 5 and Figure 7:for the TOi3 configuration, a linear and non-linear curve fitting was conducted to model the speed-up from NetLogo to Julia. For the setup phase, a power model achieved a better fit (R² = 0.834) than the linear model (R² = 0.785), indicating a non-linear relationship. For the experiment execution phase, the non-linear (logarithmic) model had a very strong fit (R² = 0.911) compared to the linear model (R² = 0.549). This suggests that while setup performance improvements were moderate, experiment runtime improvements scaled strongly in favour of Julia in a non-linear fashion.

The total execution time for the different ABMs in Table 9, Table 10 and Figure 9, shows a comparison across both machines, TOi3 and HPi5 and confirms Julia’s superiority. On TOi3, executing 30 runs required 3935.0 seconds for NetLogo but only 407.9 seconds for Julia — an approximately 9.65× speed-up. On HPi5, NetLogo took 1822.3 seconds compared to Julia’s 301.7 seconds, a 6.04× improvement. These results are illustrated in Figure 9, which shows consistent and substantial reductions in total simulation time when using Julia.

The inferential statistical analysis derived from the data shows the two models' setup-time and experiment-time. The setup time regression shows no statistically significant predictors for setup time, although the number of transactions (trans) approached significance (p ≈ 0.0875), suggesting minimal influence of model complexity on setup duration. The experiment time regression shows highly significant predictors. Notably that:

• The use of NetLogo significantly increased experiment times (β = 342.12, p < 0.001).

• TOi3 machines had longer experiment times compared to HPi5 (β = 161.16, p < 0.001).

• More nodes significantly decreased runtime (β = -4.15, p < 0.001).

• More transactions significantly increased runtime (β = 0.43, p < 0.001).

The regression models statistically validated the observed experimental speed-ups, showing that tool choice (Julia vs NetLogo) and hardware (TOi3 vs HPi5) substantially affect performance outcomes.

The effort to develop the NetLogo 6.3 ABM is significantly easier initially, but requires significantly more effort to optimise performance. NetLogo has an extensive community of users and hundreds of existing model examples. However, NetLogo 6.3 requires third-party tools to perform analysis of the data. For the IoT-DAG-DLTSim model, an extension to handle bitwise array operations was developed, and required significant resources of time and effort. In Julia, the customised “bitarray” structure or any new data structure were easy to develop, and took a minimum amount of time and effort.

The Agents.jl Julia 1.9 ABM tool has a steep learning curve, but with fewer lines of code. The language is more intuitive as you progress, particularly in the use of arrays and data dictionaries. Agents.jl Julia 1.9 ABM did not require third-party tools to analyse the data, as this comes built-in with the Julia 1.9 ecosystem. Performance improvement can be attributed to the LLVM framework.

As shown in Table 12, the regression analysis for “exp_time” revealed that both the ABM tool used (NetLogo vs. Julia Agents.jl) and the hardware configuration (TOi3 vs. HPi5) are highly statistically significant predictors of execution time, with p-values less than 1e-08. Specifically, using NetLogo significantly increased execution time compared to Agents.jl (coefficient = 342.122, p < 1e-32). Similarly, using the older TOi3 machine significantly increased execution time compared to the HPi5 (coefficient = 161.161, p < 1e-08). The number of transactions also had a significant positive impact on execution time (coefficient = 0.434, p < 1e-05), as expected. Interestingly, the analysis showed a statistically significant negative relationship between the number of nodes and execution time (coefficient = -4.15117, p < 1e-04), which may warrant further investigation. For “setup time” (Table 11), the effects of tool and transactions were not statistically significant at the conventional 0.05 level, while the machine type and nodes had significant positive effects.

NetLogo 6.3 ABM is a well-proven tool for model development and is suitable for developing proof of concepts and small models. It is suitable for researchers new to the field of model development and simulations, and provides a rich source of support, including books. However, it is limited when it comes to developing your custom extensions and native analysis and reporting, though it has a rich ecosystem of third-party integration to tools such as R, Python and Mathematica. Performance optimisation requires a good understanding of the Java Language and tools, and can prove to be time-consuming and hence expensive. In this research, it has been shown that NetLogo is not suitable for large models with many agents and calculations.

Agents.jl Julia 1.9 ABM is a recent tool with a much smaller user base and a less-known track record. However, it has been specifically designed for performance nearing that of C++, is as easy to use as Python and eliminates the need for a third-party ecosystem for data analysis. Agents.jl Julia 1.9 ABM is well suited for running large models and makes good use of computer hardware resources, resulting in shorter model run times.

5. Conclusion

This study successfully addressed its four research objectives through a systematic comparison of NetLogo 6.3 and Agents.jl in IoT-DLT simulations through temporal performance measurement, Hardware Equipment Performance Analysis and finally, tool Trade-off evaluation.

The research quantified significant execution time differences, with Agents.jl achieving 4× 10× faster simulation runs than NetLogo across varying network sizes. Benchmark data revealed consistent performance advantages for Agents.jl, particularly in large-scale scenarios exceeding 1,000 agents. Runtime comparisons across laptop configurations demonstrated that hardware improvements benefited Agents.jl disproportionately - newer hardware yielded up to 10× speedup versus 4× on older systems. This identifies Agents.jl's superior utilisation of modern multicore architectures. The study systematically contrasted the platforms' strengths: NetLogo’s simplified development environment versus Agents.jl's computational efficiency. A decision matrix was developed weighing setup complexity against runtime performance for different research scenarios.

The advantages of modern ABM were clearly demonstrated in the execution phase benchmarks, which conclusively proved Agents.jl's superiority for compute-intensive models, while also identifying NetLogo's continued relevance for prototyping and educational applications. The study's findings on the performance comparison of NetLogo and Agents.jl were empirically validated and statistically robust due to the use of inferential analysis based on the regression techniques. Therefore, these findings provide researchers with empirically validated guidelines for ABM tool selection, particularly for transaction-intensive IoT-DLT simulations. The results confirm that modern frameworks like Agents.jl can overcome traditional scalability limitations, though future work should explore parallel agent execution and memory optimisation to further enhance performance. This research establishes a foundation for evaluating ABM tools in emerging distributed ledger applications while highlighting pathways for both methodological and technical improvements in agent-based simulation.

Future work should investigate how to leverage Julia's multithreading or other parallel features to allow multiple agents to process transactions concurrently. This could potentially further improve execution times significantly, taking full advantage of multi-core processors, thereby enabling researchers to simulate even larger networks or explore a wider range of model parameters.

ACKNOWLEDGEMENTS

This research has not received any external funding and is fully self-funded.

Statement of Competing Interests

To the best of my knowledge, the authors have no competing interests related to this research.

List of Abbreviations

A-UMLAgent Unified Modelling Language

ABMAgent-Based Modelling

CTPSConfirmed Transactions per second

DAGDirect Acyclic Graph

DBDatabase

GPUGraphical Processing Unit

GUIGraphical User Interface

HPi5HP Victusi5 (Hardware configuration B)

IDEIntegrated Development Environment

IoT-DAG-DLTSimIoT-Direct Acyclic Graph-Based Distributed Ledger Technology Simulation

IoT-DLTInternet of Things Distributed Ledger Technology

JLJulia ABM

JVMJava Virtual Machine

LLVMLow-Level Virtual Machine

MASMulti-Agent Systems

MTLMean Transaction Latency

NLNetLogo ABM

PAPreferential Attachment

PDFPortable Document Format

PNGPortable Network Graphics

REPLRead, evaluate, print, loop

SIRSusceptible, Infected, Recovered

SVGScalable Vector Graphics

TOi3Toshiba i3 (Hardware configuration A)

Notes

{1}. Custom developed extension

References