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.
[ BUILD # : 200910071536 ] [ JDK VERSION : 1.6.* ] Since Gems are common to the platform, there should be a way to scan them one time and cache the scanned information in a usable format which can be reloaded each time the IDE is restarted or a project is loaded. Currently, with 30 gems installed, it takes over 2 minutes to scan the gems alone on my machine and another minute or more for my project. The scan can keep track of which gems/versions are installed in 'gem env' and if one has changed, rescan it to update the cache. Otherwise, just reloading the optimized cache file should be significantly faster than rescanning the gems each time you load a project or the IDE.
This is supposed to work this way already, i.e. so that the gems of each platform are scanned just once, so I'm changing this to a defect. For me this works e.g. in the following scenarios: a) 1. create a new project => gems of the chosen are scanned 2. create another project with the same platform => no additional scanning b) 1. create a new project => gems scanned 2. close and reopen the project, or any other project that uses the same platform => refreshing indices, but no scanning c) 1. create a new project => gems scanned 2. restart the IDE => just refreshing indices Do those scenarios work for you, or did you have some other scenario in mind? Thanks.
I don't understand why the scanning of gems is tied to the project. While there are gems tied to projects, gems are typically tied to the (j)ruby platform itself. I would propose the system use a background thread to scan all gems within each ruby platform and cache the info in a .netbeans/... folder in an easily usable format. This file is loaded when the IDE is started and, via a checksum or date test or something, either marks parts of the data invalid (if the gem was removed) or scans the new gems if they have been added. Then we only have to scan the project files when we are handling projects. So Platform indices/data gets stored in the .netbeans folder and project specific data is stored in the projects nbproject folder. It just seems to me that this combo has the potential to make the system much more performant in exchange for some complexity.
I think I wasn't being clear - the IDE already handles scanning gems once per platform, not per project. The use case a) in my previous post was suppose to demonstrate this; if it doesn't work like that for you, it is a bug that we should fix.