Community
Participate
Working Groups
Megabytes of data from the JRE's src.zip file are read off disk in order to retrieve IMethod parameter names (below). Commenting out the code below saves this I/O. It may be possible to lazy init more of the JEM model; there looks to be a lot of potential savings in avoiding the JDT model cache (their code does this too). protected void addParameters() { String[] parmNames = new String[0], parmTypeNames = getSourceMethod ().getParameterTypes(); //FIXME dbk don't get parms by name, use arg0..n // try { // parmNames = getSourceMethod().getParameterNames(); // } catch (JavaModelException npe) { // // name stays null and we carry on // } // Temp hack to work around a JavaModel bug, above call on a Binary method may return null if (parmNames == null || parmNames.length == 0) { parmNames = new String[parmTypeNames.length]; for (int i = 0; i < parmTypeNames.length; i++) { parmNames[i] = "arg" + i;//$NON-NLS-1$ } } MethodImpl javaMethodTarget = (MethodImpl) getTarget(); List params = javaMethodTarget.getParametersGen(); for (int i = 0; i < parmNames.length; i++) { params.add(createJavaParameter(javaMethodTarget, parmNames[i], typeNameFromSignature(parmTypeNames[i]))); } }
The parameter names will not be lazily initialized... so that only a call to JavaParameter.getName() will induce the source reflection. VE makes use of Parameters mainly for type and cardinality not for names (which will typically be used for code assist and code generation). for scenario 4 (close project, open project, and bring up Admin) about 14.8% improvement Before 5.752 with 0.214 stdv With Lazy name 4.897 with 0.238
Last comment ment to say that with this fix, the src. reflection for parameter name will be done lazily when a JavaParamenter.getName() is called. At this point reflection for all the parameters of the Method will be done.
Almost a second faster, I'll take it! Thanks Gili...
These were missed originally as being done for 1.1M1