Avoid overhead of VALUE_GLOBAL by storing the filters when they are added

[fingolfin]

How about looking up the filter for a given name once, via ValueGlobal, when adding the filter?

Or even don't use names at all, just let the user specify properties (or other filters) directly? If there is a reason for not doing that, perhaps document it, at least in a source code comment?

[fingolfin]

Of course using a record lookup also has some overhead. But you could perhaps avoid all of that if you just work directly with flags. Granted, those are not documented for end users, but neither is VALUE_GLOBAL, so you seem to be willing to deal with some low-level stuff ;-).

I'd make a more concrete suggestion, but lacking any examples, and given the state of the documentation, I'd have to reverse engineer how I think you intend to use this in order to make a workable suggestion. See also issue #7

[fingolfin]

To be slightly more concrete, though: in AddPropertyIncidence, instead of storing property_depends_on directly, you could store an enriched lists, with triples:

property_depends_on := List(property_depends_on, name -> [ name, ValueGlobal(name), RNamObj(name) ]);

Then in __ATTRIBUTESCHEDULER_evaluate_recursive, don't just pass the name, pass this triple. Then you can replace VALUE_GLOBAL( name_property ) by triple[2], and also spanning_tree.( name_property ) by \.(spanning_tree, triple[3]). (Of course you might not be interested in this optimization which avoids the hashing, which is rather faster anyway, and just use a pair instead of a triple).

Of course this alone does not solve things, as you also do all_names := NamesOfComponents( graph );. This, too, can be avoided, but I kind of wonder if one can't do much better by using FILTER_FLAGS etc., but a I said, it's a bit tiresome to reverse engineer the intent of the code, so I'll stop here for now :-)