Each of those task_create calls is roughly 10,000,000,000 / 250,000 = 40,000 instructions.
Thats 40'000 instructions of pure overhead as it does not contribute to the task at hand (accidental complexity).
Each of those task_create calls is roughly 10,000,000,000 / 250,000 = 40,000 instructions.
Thats 40'000 instructions of pure overhead as it does not contribute to the task at hand (accidental complexity).
edit: I'm not actually sure you are counting the context switch, but I still don't think estimating instruction count that way is particularly useful.
Having an operation that can be executing 250,000 times per second on a modern processor is extremely slow... not fast.
You wouldn't be able to write your comment if the browser were written in extremely efficient assembly code because it wouldn't exist.
NASA and every big organization also has a lot of waste, but only that way you can get to the moon.
If you didn't prevent preemptive context switches during your benchmarking, it's entirely possible the only thing you measured was the context switch time.
This is a fun experiment, but to get a rigorous idea of the overhead involved takes more work than what anyone in the post or comments has done.
Reasonableness is relative and use case dependent. The post itself illustrates how the cost is insignificant compared to other "wasteful" operations related to CSS handling.
If this is too much overhead for your use case, there are plenty of other approaches and languages to choose from.
If you're not any better, just replace your whole hosted concurrency system with a statement that triggers sched_yield.