How I put .NET into Firebird database engine
summary
Plugin embeds the .NET runtime into Firebird so stored procedures and functions run inside the database address space and transaction context, using C++/CLI shim plus an AssemblyLoadContext and self‑contained .NET Core 3.1 in a fbnet external engine folder. Hot‑reload is simulated by loading assemblies from byte arrays rather than true unloading. Performance tuning uses unsafe memory marshalling, Reflection.Emit, value tuples and ref returns; measured results show 1.11 µs per function call and a stored‑proc scenario ~42 ms vs 46 ms (1.09x), trading some speed for stability.
AI-written summary · about
chapters (19)
- 0:00Start
- 6:53Prerequisites
- 8:54Start
- 13:02AssemblyCache
- 14:03Value Tuple
- 21:48DelegateBuilder
- 25:19Caching Type for comparison
- 25:50Enum for Type
- 26:56Dictionary with delegates
- 29:23Local.NET Core loading
- 31:48Specific code
- 36:19Unsafe and void
- 38:31Less indexing, RO structs, ref, in
- 40:10C++/CLI pieces without managed
- 41:57Split "generation" from "invocation"
- 43:36Less Arguments instances
- 45:31Switch to Reflection.Emit
- 47:26Hot-reload revisited
- 49:15What's next?
related talks
32mBuilding .NET software with focus on performance and scalability
47m.NET Blub: Frameworks beyond Microsoft
01h 02mHow to Scale .NET Apps with Distributed Caching
59mEF Core 6: Fulfilling the Bucket List
15m100x faster data app experiences delivered cost-effectively
18mPerformance Profiling in FoundationDB
01h 02mUnlocking the Full Potential: The Harmonious Dance of EF Core and SQL Server
01h 08mFirebolt: Why Powering User Facing Applications on Iceberg is Hard