Skip to main content
SimilarExport ZIP
100%

Wrong performances of the closest_to operator in Gama 1.7 (dev)

✓ Published0🌍 Public
RRCura
Last edited Oct 30, 2015
Created on Oct 30, 2015

This example benchmarks the performance of three different methods for finding the nearest neighbor among agents in the Gama 1.7 platform: the built-in `closest_to` operator, an optimized variant using `at_distance`, and a manual `minDistance` calculation via distance collection. It measures execution time across four population-size scenarios, from 100 to 10,000 calling and called agents, writing the results to the console. The code uses Gama’s agent-based modeling API, including `create`, `ask`, `machine_time`, and spatial queries like `closest_to` and `at_distance`. The visualization demonstrates how algorithmic choice and agent density affect computational performance.

AI-generated description

Similar vizzes

Loading thumbnail…

Gist de70ab070f96fd7c413f

This GAMA model benchmarks four spatial query methods—`closestTo`, `optimClosestTo`, `minDistance`, and `basicClosestTo`—across varying agent population sizes and geometry usage. It compares execution times for high- and low-caller/called agent counts, with optional circular geometries for agents, using `machine_time` for timing. The simulation outputs performance ratios per cycle, demonstrating how each method scales under different spatial configurations and query loads.

RRCura
81% match
Loading thumbnail…

Gama : batch mode errors

This example compares two GAMA batch-mode experiments, “Bugged” and “Working,” that simulate a simple infection spreading among 300 moving people. It shows how a subtle output error—plotting the count of immune agents instead of infected ones—yields a misleading chart, while the corrected version tracks the actual infection count. Both experiments use GAMA’s `chart` display with a series type and `value:` data source, repeated five times with fixed seeds. The model relies on GAMA’s `people` species with `skills:[moving]` and the `wander` reflex for spatial dynamics.

RRCura
59% match
Loading thumbnail…

Gist 294bf474d3283271f3e967f4e15f0d03

This example runs a sensitivity analysis on a GAMA agent-based model, testing a wide range of parameter values to assess their influence on simulation outcomes. It defines dozens of parameter ranges (e.g., distances, probabilities, counts) via R’s `seq()` function, then generates an XML experiment plan for headless GAMA simulations, launched in parallel across 24 cores using a Bash script with `taskset`. The visualization itself is not produced here; the code focuses on experimental setup and parameter sampling.

RRCura
57% match
Loading thumbnail…

globby - chuhai

This example compares the performance of two glob-matching libraries—the local `globby` fork and the upstream `globby` master—against `glob-stream`, using the `chuhai` and `ava` benchmarking suites. It shows raw operations per second for three pattern scenarios (negative globs and multiple positive globs) across async and sync APIs, with results from 10 runs each. The code directly invokes `globby.sync()`, `globby()`, and `glob-stream`'s `create()` to measure throughput, while the markdown output lists the fastest implementation per test. Data is generated from a temporary directory containing 500 files per subfolder, and the rendering is plain text from benchmark results.

HHypercubed
52% match
Loading thumbnail…

Gist d6bacd4ce0d5835b801ba028f9b1c81b

This example benchmarks seven JavaScript object-cloning techniques using the `chuhai` benchmarking library, with `lodash`, `Object.assign`, and JSON methods. It compares operations per second for deep and shallow copies of 1,000 parsed CSV records fetched from a remote dataset. The visualization highlights relative performance differences through horizontal bar lengths, with the fastest method labeled explicitly. The code uses `babyparse` for CSV parsing and `platform` to report the runtime environment, while the benchmark logic is orchestrated via `suite.cb` and `s.bench` calls. Results are output as Markdown text, not rendered graphically.

HHypercubed
51% match
Loading thumbnail…

Gist e92adbf79e3256a0d3e222f140a0433b

This example visualizes the relative performance of 16 JavaScript event-emitter libraries across two benchmark scenarios, “emit objects” and “emit one parameter,” using the raw output of the benchmark runner. The data, drawn from a gist by Hypercubed, is rendered as a grouped horizontal bar chart where each bar’s length corresponds to operations per second (ops/sec), with libraries sorted by speed and the fastest highlighted. The chart uses a simple SVG-based custom layout (likely with d3-scale for axes and d3-array for sorting) rather than a high-level charting library, directly mapping the numeric values to pixel widths. The visualization does not show error margins or statistical significance, only the raw ops/sec values and the benchmark’s “Fastest is” annotation for each test.

HHypercubed
50% match
Loading thumbnail…

Gist 24579e225fd76065b0ac0e72b36ea31b

This example demonstrates a performance profiling visualization for a force-directed graph simulation. It shows how long the `returnLast` function takes to execute on a dataset of star objects, displaying the elapsed time in milliseconds alongside console output. The visualization uses D3.js’s `d3.forceSimulation` to animate the graph, while custom timing logic captures start and end timestamps via `Date.now()` to measure iteration performance. The code logs the star count and elapsed time to the console, iterating through multiple frames to track timing variations. The rendering approach relies on D3’s simulation engine, with the data source being a static array of star objects defined in the script.

WWill Carter
50% match
Loading thumbnail…

Comparing the performances of various DBMS using dplyr for large-ish data

This example compares the execution times of data manipulation operations across different database management systems using the `dplyr` and `dbplyr` R packages. It benchmarks a `group_by` with `summarise` and a `left_join` with `mutate` on a 50-million-row tibble, running the same queries against in-memory data frames, SQLite databases (in-memory and file-based), and PostgreSQL. The code uses `system.time` to measure the elapsed user and system times for each operation, recording results in a benchmark summary table. The visualization highlights performance differences across database backends for typical data wrangling tasks.

RRCura
50% match