I haven't looked at the implementation, but this seems to imply it is very I/O intensive and already takes a very long time in RAM. Yet, nothing about the problem statement suggests it would be such a task --- it sounds like something that could be very straightforwardly done completely in memory.
It was only a couple minutes. That's a bit disappointing.
If this program needed to operate from memory instead of a disk, why didn't the coder just... code it that way? Are they saying to use a RAM disk to ensure you don't encounter automatic paging out to disk by the OS?
It requires file paths, and it will be doing a large amount of reading. Easiest way of solving this is probably just to fake that your memory is a hard drive.
Don't put your work down like this. You created something useful for yourself, and likely useful for others. I'd be surprised if someone called it stupid.
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.
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.
[1] http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=...
Yes, that's how you can fit all of Unicode into one "font" -- use a collection of fonts with at most 64K glyphs each:
https://graphicdesign.stackexchange.com/questions/73166/what...
I'll leave it as an "exercise for the reader" to generate such a font.
If you're using ubuntu, there's a package for it
It's designed with GNOME in mind, but not part of GNOME itself, so installing it doesn't require pulling a huge part of GNOME either, and that's a nice plus! :)
how does it handle combining characters? do they get everything in a single box or are going to be rendered as two boxes?
The data is gone if you restart tho.
Imagine if there was no lag opening any app because everything was in memory. Imagine your code getting simpler because you don't need to load assets off disk - that's done all in one go at boot time. You want to render an image out? Just do it - a reference to a file is a reference to a file, no loading it or wondering if it's loaded.
Flash storage in phones is fast enough these days that it's probably not worth it, and simply giving traditional phones lots of RAM will probably give 80% of the improvement for 20% of the cost. But I've been curious about the idea for some time.
/dev/shm, on the other hand, is almost always guaranteed to be a tmpfs on glibc systems.
RHEL7, and all it's derivatives (CentOS, Oracle Linux etc.) don't use tmpfs for /tmp by default, and they are arguably the most used linux distros in the world.
e.g I wanna try it but i'm TOFU
