This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
During the folder expansion ConfigDataLoader is queried if it recognizes files. This evaluation in findPrimaryFile method is visible in my profiler so it is probably worth optimization.
Created attachment 17142 [details] minor optimization
Pavle, can you review the patch that tries to avoid repeated calls to getNameExt?
I was the last touching this getPrimaryFile method. So I volunteer to own this issue. I have implemented the recommended changes to avoid repeated call to getNameExt. FileOwnerQuery and J2eeModuleProvider lookup take ~0 ms. Only improvement left is the first time calling to J2eeModuleProvider.findDeploymentConfigurationFile(primaryName) takes less than 10ms. Will look more into this call for further first time improvement.
Thanks, this can be sufficient. The repeated calls made it visible in my profiler. No need to spent more time than necesery on it. Of course I do not develop j2ee apps so there can be other possible improvements if you work on some j2ee/web project
Since performance was improved, could the priority be decreased to P4?
it can
reassign for proper reevaluation in current context of the code.
ConfigDataLoader does not exist any more, so Petre H, I guess this can be closed?
I've found one ConfigDataLoader in Sun J2EE DD GUI. However because I didn't find any usage of this class so maybe it is a dead code.
Reassigning to the owner.
ConfigDataLoader in sunddui is dead, last active in 5.5.1. It does need to be removed.
Well, removing it is a special case of making it faster (every registered DataLoader slows down the IDE) :-) Reopening until you actually remove it.
It's not registered and hasn't been since around NB6 M6-M8 timeframe. Are you saying that existence of the class in the module jar is causing a problem? I haven't seen any such problems.
> It's not registered and hasn't been since around NB6 M6-M8 timeframe. Great. Why don't you remove it then, it should be easy. > Are you saying that existence of the class in the module jar is causing a problem? No, not really (except for bigger jars and all that theoretical marginal influence) Well, there seems to be a lot of dead code then - ConfigDataLoader is not registered, so noone can produce valid ConfigDataObject then. And there's a lot of "functionality" bound to ConfigDataObject, isn't there?
I suggest to leave this open for now and I am decreasing priority to P5.
It's on my list. Just not as simple as you think and I've been tasked with higher priorities right now.
I'm wondering why someone removed it from manifest without deleting of the class. I am even more wondering why we did not requested to fix this as a part of commit review when this changed happened. Technically it is possible to write a test checking that all Loader subclasses in the IDE are registered in some manifest or have another subclass but this is rare and it is better to catch such half-done changes when they are commited.
do you think this is a P3, tm 6.1 item?
ConfigDataLoader sources have been removed.