# Dusk OS approach to speed

The vast majority of the hardware that Dusk is going to run on is massively
overpowered compared to Dusk's typical workload on it. Speed is therefore de-
priotized. It doesn't mean, however, that we squander the computing ressources.

As with anything in Dusk, we aim for efficient code as long as it doesn't hinder
simplicity and grokkability. Where is the tradeoff cutoff? Difficult to say.
Let's use an example: the word "fill". This word is not needed by the native
kernel, so it's implemented in Forth in xcomp/boot. The operation is simple:
we fill memory with a value. The Forth loop is very, very inefficient compared
to a native loop. For each byte we copy, we have to play around with PS and RS a
lot. An efficiency nightmare!

Dusk's cutoff is below that. We like simplicity, but that inefficiency is too
much for such a core word. For this reason, we prefer to implement it in HAL
even though it's less readable and more verbose.

Another example is the way "to" semantics is implemented. It's certainly more
mind bending to comprehend how it works than if it was a naive and straight
implementation of the concept, but those "to" words are absolutely everywhere!
To allow them to leverage the HAL and compile themselves as native operations
brings speedups that are really too great to pass.

However, as we go further away from Dusk's core routines and towards "leaf"
code, speed is deprioritized and grokkability takes its place.

## Caching

In software, caching is a major source of complexity. The layers of indirection
it brings means we're seldom quite sure of what happens exactly when we call a
piece of code because it depends on many runtime factors.

Dusk OS has as little caching as possible to be functional. That is very little.
For example, to be able to write to a 512 bytes sector, one has to read it in
memory first. Of course, we could go with a strict "no caching" policy and have
every little byte written involve a sector read followed by a sector write, but
that would be stupidly inefficient, so filesystem handles maintain a sector
cache along with its dirtiness status. But no more.

Let's use another example, the FAT table. When seeking entries in a FAT FS, the
FAT table is heavily sollicited. Caching it in memory would speed up things, but
then one has to manage cache invalidation when the FAT changes. Therefore, we
do the same thing for the FAT as we do for file handle: a single sector cache
along with a dirtiness flag. This makes FAT seeking slower (unless we're lucky)
but the code simpler. But yes, this means that Dusk OS has slow FAT access.

Therefore, we could say that in Dusk, cache isn't related to speed, but to
function.

Does it mean that the Dusk OS operator can't use their gigabytes of memory to
speed up their operation a little bit? No, it doesn't mean that. They can cache
their stuff, but on their own terms and explicitly. Core routines don't cache.

## Filesystem speed

Dusk OS is memory oriented, not file oriented. There are very few scenarios,
actual or imagined, where mass storage access becomes a critical bottleneck.

Therefore, we accept that filesystem access is inherently slow. The FS API is
written with that understanding. This, of course, doesn't mean that we squander
ressources, only that simplicity has much more weight than speed with regards to
the filesystem.
