Let me start with a disclaimer and explanation. I wanted to have font
metrics for a set of Unicode fonts available to some SML code. The metrics
are extracted from the font by a cascade of programs and I already had
code to inject them into C projects by creating files that went
static font_info[] = {
... ... ... };
with MANY lines of simple static data. Doing things that way puts the
metric data instantly available within my program. I modified things to
create the same in SML and ended up with
val metrics = Vector.from List [
Vector.fromList [a,b,c,d,e,f],
Vector.fromList [a,b,c,d,e,f],
.. ];
with around 10000 entries in the top level list. This was simple to do and
in particular simpler both now and for when/if the code gets used by
people. In particular simpler than anything that has SML code that reads
the metric data from a resource file. And I am only interested in the
metrics I have right now and am not concerned about future expansion there.
Processing the input there works, but takes around 10 minutes of a
reasonably fast desktop machine. That felt pretty bad.
If I change the code to go (as it were)
[[x,x,x,x] @ [x,x,x,x] @ [x,x,x,x]]
at the top level with say 200 "x"s in each segment and 50 segments then
the code is processed in more like 10 seconds rather than 10 minutes.
This feels as if it is probably a really easy case where some aspect of
processing lists in the input has been coded with quadratic growth rate in
a way that is probably not necessary (the fact that the version segmented
using "@" gets handled faster reassures me of that).
A really easy demo if this is just
val l = length [
Vector.fromList [0],
... ];
with 10000 entries in the list.
I understand very happily that this is pathological code that nobody would
ever write by hand and that as a way of handling data can be viewed as
inflexible and crude. I am also happy that I can work round it using "@"
and so it is not holding me up - but it felt as if it might be worth
reporting and my expectation is that a very small change to the code would
address it. I had looked and the code getList in SKIPS_.ML might have been
the issue, but when I recode that to build the list backwards and then
reverse at the end that does not unclog things, so the issue is at least
one step deeper.
Arthur
