💾 Archived View for stack.tilde.cafe › gemlog › 2022-12-27.is_it_fast.gmi captured on 2023-09-28 at 16:08:55. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Is harn fast enough?

I became a bit concerned that my relocation/garbage-collection speed might make the system sluggish.

Consider that after editing and recompiling a function,

all references to the old one need to be fixed up to point to the new one;
the old one must be deleted, moving all functions above down;
all references to moved functions must be fixed up;
the metadata for old function must be deleted, and all metadata above moved down;
metadata linkage must be fixed up.

So this is a lot of work requiring moving tons of memory and walking the relocation bitmaps adjusting tons of references.

The last time I worked with this tech, in production, was on a 486, and garbage-collection delays were an issue! Back then I even devised a way to delay GC until manually triggered at a more opportune time, and was known for typing 'gc' absentmindedly they way some old-school Unix guys type 'sync'...

So I got a little scared last night, and concocted a stress test.

First I ingested my old 'hello world' function foo. Then I ran my stress-test function, which created 100,000 copies of it with different names. So,

> sys
    DATA     CODE     META
80000008 4030E260 C0559088

So I have 3.2MB of code sitting on top of foo, 100,000 symbols in the namespace. It still works; good.

Next I recompiled foo. Since it's at the bottom of the pile, everything else will need to drop... Will it take long?

> cc
Ingested foo: extern void foo (void); 25 bytes
300005 fixups
>

Boom. A tiniest of delays - maybe a 10th of a second.

300005 fixups. Not bad for a toy. And it works - hello, world.

I will rig up timing instrumentation and telemetry soon and really know the answers - about what is causing the delay and much more. But, looks like I don't have to worry about it too much.

index

home