Sander Mertens SanderMertens

v2.2 benchmarks

Measurements are per operation. Measurements for bulk operations are scaled to the number of entities. To minimize the impact of scheduling and improve reproducibility, each measurement is done N times, for which the minimum and average time are calculated. The minimum time is the most reproducible, as this is the time with the least impact from the OS scheduler. As the times for most operations are measured in nanoseconds, each measurement measures an operation executed many times (typically 1 million). This minimizes the impact of clock accuracy issues and the overhead of measuring time.

ns = nanoseconds, us = microseconds, ms = milliseconds

Entity creation	Min	Avg
flecs.new_id	9.459 ns	11.009 ns
flecs.new_id_recycle	2.763 ns	3.198 ns

V3 roadmap

This is a list of planned features for v3

Declarative APIs

Less but more powerful API calls, following a more declarative design as described here: https://gist.github.com/SanderMertens/40bf6cd98dc658443651125e6dee5c28

Hybrid storage

A hybrid model that supports archetype and sparse set storages. Applications will be able to upfront specify which components are stored in a sparse set, and which components are stored in an archetype. The API will work transparently with either storage. Queries will transparently query across sparse sets & archetypes if needed.

ECS Query DSL draft

Proposal for prolog-inspired ECS query DSL that can resolve components as well as entity relationships. Not a formal syntax/grammar definition.

Overview

Primitives

.                             // Self. Indicates iterated over entity or entity for given (arche)type
Entity                        // Entity identifier
X                             // Variable (all caps identifier)

Plecs draft

Prolog with Flecs extensions. Follows same conventions as https://gist.github.com/SanderMertens/2b0aa555601e218ea27af1096a4cc838

Atom

Simple (named) entity definition. The dot is optional (to make prolog compatible).

Bob
Alice.

Atoms (entities) are created on first occurrence.

Introducing relationships to ECS (draft)

After traits were added to Flecs, use cases have been identified that use the feature for describing & querying entity relationships, and by extension, knowledge graphs. The initial terminology used to describe traits does not really match these new use cases. Additionally, terminology around traits is sometimes ambiguous and unclear (a trait is the combination of a component and a trait?).

This draft proposes to establish a conceptually sound framework for introducing semantic graphs/entity relationships to ECS, in addition to providing unambiguous terminology that better matches what is already established by literature (such as by logic programming, RDF, semantic web, ConceptNet).

Introduction

This section provides a high level overview of semantic data structures and first order logic programming and is not specific to ECS.

Semantic graphs are typically stored as a collection of triples, which take the following form:

	#include <transform.h>

	typedef float vec3[3];
	typedef float quat[4];
	typedef struct mat4 {
	float value[4*4];
	} mat4;

	typedef struct transform {
	/* Individual components */

	struct Threshold {
	float value;
	};

	struct Blur {
	float radius;
	};

	struct HBlur : Blur { };
	struct VBlur : Blur { };

	// Draft for low-level macro-less API
	//
	// The goal of this draft is to explore a full-featured minimal API that does not rely on macro's. That should make it easier to port
	// flecs to other languages, and allow for more straightforward integration with other frameworks / engines. This is not meant as a
	// full replacement for an application-facing API, though should be able to coexist with one.
	//
	// Inspiration for naming conventions & declarative design comes from Sokol Gfx

	// Create world as usual
	ecs_world_t *world = ecs_init();

	typedef float vec3[3];
	typedef float quat[4];

	typedef struct mat4 {
	float value[4*4];
	} mat4;

	struct transform {
	transform()
	: pose({ })

	// Draft for manual creation of deferred command queues.
	// There are three basic requirements for the API:
	// 1. Allow for population of a command queue from external source (not flecs API)
	// 2. Record operations and take control over how they are flushed
	// 3. Allow for pushing operations to different queues
	//
	// All requirements must work in multithreaded applications, and for applications with multiple synchronization points.
	//
	// High level design:
	// - Application can create a defer context. A single defer context contains a command queue per thread.