[Retr0spectrum]

> WARNING: PLEASE DO NOT RUN THIS CODE ON A HARD DRIVE, I'M NOT SURE HOW LONG IT WOULD TAKE. I USED A RAM DISK

How much disk IO does this program generate? Why?

In any case, the OS should cache stuff and give similar performance to using a ramdisk, provided you have enough spare ram.

[13of40]

> the OS should cache stuff

When I worked at Microsoft back in the 90's I inquired around building 26 as to why I couldn't create a ram disk on what was to become Windows 2000, and this was basically the answer. So yes, if caching doesn't solve this then caching hasn't been implemented correctly.

[MichaelGG]

What if you're using a program that fsyncs? And the filesystem isn't just keeping writes cached and flushing only when full. So if I'm writing GB of temp files, I'm causing tons of disk load which may impact other programs. Can't seek to read while writing all my temp data...

[Dylan16807]

> What if you're using a program that fsyncs?

Remove the fsync or use libeatmydata.

> So if I'm writing GB of temp files

The kind that won't fit on a ramdisk in the first place? And this particular use case shouldn't need that.

[MichaelGG]

The scenario is I'm running a DB on the same system as temp program. Also, machines with many GB of ram are popular these days.

[Dylan16807]

If fsync on one file forces all other files to disk, then it is 100% an OS performance problem.

If your temp files fit in ram along with running programs, then they should stay cached. A ramdisk should only be needed in edge cases where you want to manually force other things out of memory, or because you particularly want to avoid extra writes to disk. In general performance is supposed to be boosted just as much by caching.

[MichaelGG]

If your disk head is writing the temp file, then it can't be sitting idle waiting to fsync. And it'll eventually write as part of checkpointing.

[13of40]

That's actually a good point.

[juanpotato]

Fontforge doesn't have a function for loading svgs as glyphs from strings. Only files paths.