The 11 secs versus "LONG TIME" comment was related to examining 120 triples with 90+ constraints. When I had a couple thousand triples with the same number of constraints, I gave up waiting since I knew that my customers would not accept the delay.
My constraints are a translation of the Security Markings Schematron rules found at
http://www.dni.gov/index.php/about/organization/chief-information-officer/information-security-marking-metadata. On that page, there is a download for the
XML Data Encoding Spec for Information Security Marking Metadata. If you unzip the file, and go into the Schematron/ISM directory, you can find the rules. There are more than 90, but I was focused on examining ones that apply to sets of resources.
To get the necessary response speeds, I reduced the number of triples to a minimum by defining attribute value combinations that were specifically involved in the constraints, and then I refined the SPARQL constraints to use only very basic syntax. The first step is problematic in that I have to change code as the constraints are expanded, in order to bring in more combinations or values (or both). The second step is not problematic, but I wonder if you have any documentation on the performance implications of different constraint syntaxes (OWL versus SPARQL, or SPARQL UNION vs FILTER (?someVariable IN (<URI1>, <URI2>, ...)), etc.).
Also, I seem to have stumbled onto a bug related to UNION vs FILTER...IN, but I will use a different post to explain the issue.