The Limits of Devirtualization

[iFreilicht]

@mnemnion

It mostly does actually. 106 (107? ehhh anyway), 64 bit system, 106 pointers, 848 byte VTable. Four categories, four more words , 880 bytes.

@Lowell

I think what iFreilicht is referencing in terms of my idea not solving the size problem is the memory required to store the Io object, which is miniscule on desktop platforms but may actually be significant on lower-power embedded projects.

That’s exactly right! This was pointed out to me by @buzmeg here.

1KB is a lot of data to store in RAM by default in an embedded context, and that’s just the current state! Looking at the current status of #30150 - Migrate all applicable I/O APIs to `std.Io` - ziglang/zig - Codeberg.org it seems to me that number might still double or triple before the feature is done.

An Arduino UNO has 2KB of RAM^[1]. I don’t think we want stdlib’s runtime memory footprint to be so big that you can’t use it on a budget chip like that. The entire point of Io is that it makes libraries portable across a wide range of platforms.

This is also relevant when compiling to WASM for the web, as every additional KB reduces the amount of time taken until your code can actually run.

---

1. From what I remember the Atmega 328p is an 8-bit chip, so pointers on it should be much smaller, reducing the size of Io.VTable, but this doesn’t invalidate the argument. ↩︎