Oh, I didn't know about the O(N) performance of getMethod, and that's really unfortunate. I assumed it would use a HashMap or something (maybe a "perfect hashmap", since all the methods are known in advance), since that's O(1), but probably the Java designers were counting on the number of methods in a class being relatively small, and comparable to the complexity of hashing parameter types, looking up a hash bucket, and possibly chaining (in case of collisions).
Actually, since for a given class, the number of methods in a given class is fixed, you can think of Class::getMethod as being "O(1) per class", but O(N) across all classes...
I share your aversion to anything taking longer than O(1) or O[log(N)], but unless the number of methods you are looking up is huge, maybe O(N) for a small value of N is a cost that it would be OK to pay.
If you find you are looking up the same method many times, you could try
caching the mapping from the type signature string to the method
reference
in your own hashmap, and see if it's faster than looking it up using
Class::getMethod. I wrote a JSON parser for ClassGraph though, and used this technique internally to cache type lookups, but I found that actually it was faster just to use the reflection API, so I got rid of most of the caching. Your mileage may vary.
The alternative to using the reflection API is to iterate through all N methods, as you suggest, and for each one, match it to the M method lookups you need to perform against that class. Even assuming M <= N, if you have deduplicated method lookups, M is still O(N) -- so you are left with a total time of O(N^2) for M lookups of N methods using the Java API, or O(N + N log N) for a smart implementation that "zips together" a sorted list of the M method lookups against a sorted list of the N method definitions. You basically use a running pointer through sorted lists on the two sides of the matching problem, and step one or the other forward depending on whether there is a gap in the sorted order of one list vs. the other. This may be more complexity than you want to deal with though.
Hope this helps!
Luke