I have wroten an small patch, which accounts the frequency buffer
opening of particular files: the more frequent files are listed in the
It also disables the project update on the plugin start in case of file storage, because it resets all frequency
Tested with: SmartOpen 1.1, jEdit 5.0
|Submitted||thedmol - 2013-01-26 - 15:50:14z||Assigned||kpouer|
|2013-02-20 - 12:34:41z
|Hi, your patch seems interesting, but I'm updating the Lucene plugin to Lucene 4.1
and the api is changed a little.
The trunk of Smartopen is updated for that but the patch do not apply.
I did a change that is minor for the plugin but cause problems for your feature: the index is now always in memory.
The problem is that the frequency will be lost after restarting jEdit, do you think it is a problem or is it acceptable ?
|2013-02-20 - 17:41:57z
Yes, I know that in-memory Lucene's indices are lost after jEdit restart. But let it be decided by user weather store indices in-memory or on disk.
There is pros and cons on the in-memory storage engine:
Pros: a bit faster search and no disk memory usage (the last ins't real benefit, I think).
Cons: Usage statistics can't be persisted and a bit delayed startup or project switch (on large project the plugin re-indices whole project, which is a bit annoying).
Regarding disk storage engine:
Pros: file usage statistics can be persisted, which much improves user experience: it allows easily and quickly search necessary file on project with thousand source files. Also, it leads to a faster startup/project switch.
Cons: disk usage, and, probably a bit slower search, but I don't feel either.
The disk storage engine is preferable to me. What do you think about to switching to it?
PS. Also it is possible to use mixed approach (in theory, I don't know Lucene in details) : to tie in-memory and disk-storages : to use in-memory for search, and sync-to disk them on any changes. That also seems to be solving all problems.
|2013-02-21 - 09:44:40z
|In fact I removed the disk storage because even on a big project building the index
is very fast, and the memory footprint is very low.
Being able to work in memory is also important when running with no settings. But I will find a solution to reintegrate the disk storage.
|2013-01-26 - 19:27:34z
SmartOpen-1.1-account-frequency.patch (more accurate and error prone version)