Community
Participate
Working Groups
Build: 3.0 M6 I noticed that the background task to find occurrences in the file creates a new thread every time, rather than using jobs. This is exactly the situation that jobs were created for (in fact Erich used this as a demo of the job infrastructure at a code camp). Some advantages of changing to jobs: - less overhead (currently a new thread is created per key press, jobs use a thread pool) - better handling of priority (currently running in a thread with same priority as the UI, and thus is competing with UI thread for CPU more than it should) - smarter scheduling. Jobs with "DECORATE" priority are run based on a check of how busy the system is. Thus they do not run immediately if there are other things going on (they will run eventually, just not as quickly). This smooths over bottlenecks when the system is busy. Note that you can prevent this job from showing in the progress view or making the progress animation (cigarette) move by making it a system job (Job.setSystem(true)). Generally jobs that the user didn't explicitly start can be marked as system jobs. If there was a reason why jobs were considered and rejected, I'd be curious to know. If the infrastructure isn't useful to you then I want to fix it.
This needs to be consolidated together with the current ongoing work to have only one AST built on post selection change. Currently there's no shared AST and ever "client" needs to compute his own (e.g. occurrences finder, quick fix, ...)
Fixed. Available in builds > 20040107
