[userbinator]

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

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.

[chungy]

That warning made me want to try it on my hard disk just to see how long it would take...

It was only a couple minutes. That's a bit disappointing.

[sleepychu]

SSD or spinning platter?

[chungy]

Spinning platter. ZFS with compression is probably helping that.

[panic]

Your OS is probably caching the file at the virtual memory layer, so it doesn't even have to hit the filesystem at all.

[sillysaurus3]

A good lesson not to try to guess where the bottlenecks in a program will be. :)

[wereHamster]

mount -o sync :)

[juanpotato]

You're right and I should have added more details. fontforge only accepts file paths and not strings sadly

[monsieurbanana]

Libraries to treat strings as files are pretty common, in python they have one in the std:

https://docs.python.org/2/library/stringio.html

[juanpotato]

But that's a file, it accepts a file path. I already looked into this

[CJefferson]

It's just that the python library used won't read SVG from a string, online from a file given a filename, so each character must be written to disk, then read back in.

[userbinator]

Wow. To me that's definitely in the realm of "fix this if you need to run this program more than once" inefficiency. After looking at the implementation, it doesn't seem like it takes advantage of TTF's "composite glyphs" feature either, which would be the most straightforward way of generating a font like this --- once you define the box and the digit glyphs, each character is then composed entirely of references to the box and the appropriate digit glyphs.

[juanpotato]

Yeah I tried looking to see how much I would need to change to fix it, but I'm not too great in C which is what fontforge was written in.

Oh man I gotta look into the composite glyphs. I don't know much about fonts in general. Thanks for this bit of information.

[Zyst]

>To me that's definitely in the realm of "fix this if you need to run this program more than once"

Maybe the programmer doesn't need to use this more than once?

[ClassyJacket]

Hobbyist-only coder here who hacks together high-level crap, not memory management and such. Question -

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?

[codefined]

I believe it's a requirement of font forge that they're using.

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.

[djsumdog]

As other comments have stated, most operating systems do a pretty good job at caching this type of I/O anyway. It goes back to the idea of not optimizing until you know where the bottlenecks really are. A lot of time the underlying layers may take care of it for you.