MethodScanner performance issue

[lsuski]

Hi,
I found that MethodScanner scan() method

 public void scan(JavaBackend javaBackend, List<String> gluePaths) {
        for (String gluePath : gluePaths) {
            for (Class<?> glueCodeClass : classFinder.getDescendants(Object.class, packageName(gluePath))) {
                while (glueCodeClass != null && glueCodeClass != Object.class && !Utils.isInstantiable(glueCodeClass)) {
                    // those can't be instantiated without container class present.
                    glueCodeClass = glueCodeClass.getSuperclass();
                }
                if (glueCodeClass != null) {
                    for (Method method : glueCodeClass.getMethods()) {
                        scan(javaBackend, method, glueCodeClass);
                    }
                }
            }
        }
    }

is very unoptimal for annonymous classes and generally not instantiable classes. For those classes glueCodeClass variable becomes Object.class which is useless. Then method scan() checks Object public methods against appearance of about 400 possible cucumber.api annotations

[aslakhellesoy]

Do you have any benchmark numbers? Any suggestions?

[lsuski]

I found this while resolving issue with Android Studio 1.5.0 debugger, starting tests with debug takes very long, about 10-15 minutes, and I found that execution hangs on scan method. Without debug it executes normally so it's not really cucumber issue. I think that adding this would be sufficient

if (glueCodeClass != null && glueCodeClass != Object.class) {
                    for (Method method : glueCodeClass.getMethods()) {
                        scan(javaBackend, method, glueCodeClass);
                    }
                }

[aslakhellesoy]

Feel free to send a pull request. You're in the best position to judge how well it works for you.

[dherges]

reference from 1034 was typo. please ignore. no relation between the two.

[mpkorstanje]

Closing. It appears this issue has been resolved a while ago.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.