SVG import performance / scaling issue

Glyphs
1

When importing SVGs (color + outline), Glyphs.app scales with the number of SVGs non-linearly (in memory and processing time). This is very strange, since I expected each import to be independent of previous or subsequent imports.

The following are some stats (minutes, RAM):

1500 SVGs, about 8 Mb

  • 2:43, 0.85 Gb
  • 2:59, 1.2 Gb
  • 3:07, 0.31 Gb
  • 3:14, 0.47 Gb

3000 SVGs, about 16 Mb (expecting ~6 min, <2 Gb)

  • 19 min, 2.9 Gb
  • 22 min, 3.4 Gb

With 3,000 SVG imports, there is also an irregular, maybe 1-in-8, chance that the memory usage just completely blows up to 80–180 Gb (!!) at which point Glyphs just requires a force quit. (I’m not sure why; restarting, and importing exactly the same files would work the second time.)

image
image1920×733 102 KB

It may be possible for you to find out more about this by duplicating then importing the same SVG n times, and profile the parts of the code that scales as quadratic/cubic when n grows.

(And then, it is not clear to me why (1) attaching a pointer to an SVG file, and (2) converting SVG paths to draw instructions should to take so much memory; in the last case it’s 1.2 Gb ram / 1 Mb on-disk!)

I am working on CJK fonts with > 50,000 SVG imports / font, and I’m looking to release 7–8 variants. It would be nice to be able to be able to reliably import in one go, instead of baby-sitting (35x8) = 250 manual operations.

2

Could you send me those svg?

3

Done （@support)

4

If you do memory intensive operations in a loop, you need to help the MacOS memory management a bit.

In the first line of the loop, add this line:

from Foundation import NSAutoreleasePool

for foo in bar:
    pool = NSAutoreleasePool.new()
    # do stuff
5

I have now tried this five seven times with the same font and same SVGs. Yes, adding Autorelease to the top of the loop improves the memory management: the 38,000 SVGs (~150 Mb) could be imported in a single go, and when this happens, the memory usage is only around 30 Gb.

This, however, does not solve the non-deterministic memory usage problem; 3/5 5/7 of the attempts blew up in memory use and ultimately never got completed.

6

Can you send me the bigger part of the .svg? I need to run that in the debugger.