I'm seeing some very odd (to me, at least) behavior with 1.5.1b.
When I try edit a particular .properties file, the editor seems to present two properties files: the one I'm editing (cons.properties) and another whose only relationship is that its name is similar (console.properties).
In addition, in this mode, there is an extra window underneath the "key tree" window displaying the names of the two .properties files (with one of them, console.properties, displayed in red). Finally, the keys displayed in the "key tree" are displayed in red and include keys for both .properties files.
Hi, Yes it's bug, in this case files starts with cons* and PE thinks they in bundle. But 2 editors mode is "bundle mode" and behaviour you described is normal in future version I'll address this issue.
It also takes 3 minutes when I change the delimiter.
From this finding it seems that the file is reparsed when one switches the delimiter.
A couple of stray thoughts I am having regarding potential optimizations that you may or may not already have: 1. Parsing could be in 2 phases - a HashMap of the identifiers as they appear in the file (mapping of identifier to line number, value pairs to cover duplicated identifiers), and a tree structure that will be created out of the HashMap, thus allowing easier switching of delimiter. 2. HashMap and tree could be initialized with the number of lines in the file. That will create some memory overhead (as there are empty lines and comments) but will avoid excessive reallocation and garbage collection while building the map or tree. 3. If you are reading the file character by character and parse it while reading, it might be worth it to read the whole file and then work on it. 4. If you do the parsing in the background and update the tree view gradually while allowing to edit the file in the same time, and then parse the changes to a copy of the file before the editing was done, then update the copy after you finish parsing the changes, even if it is still slow, it will not hang IntelliJ for the parsing time and will allow smoother work.
A simple calculation shows that around 4500 entries take around 3 minutes (180 seconds), i.e. 4500 / 180 = 25 entries are parsed per second, and that seems slow for a Pentium 4 1.6GHz with 1GB of memory with 400MB unused).
Hi, It works almost as you described and very strange so poor performance. In future versions I'll add more diagnostics. But even scrambled version of your file will be useful anyway.
I'm seeing some very odd (to me, at least) behavior with 1.5.1b.
When I try edit a particular .properties file, the editor seems to present two properties files: the one I'm editing (cons.properties) and another whose only relationship is that its name is similar (console.properties).
In addition, in this mode, there is an extra window underneath the "key tree" window displaying the names of the two .properties files (with one of them, console.properties, displayed in red). Finally, the keys displayed in the "key tree" are displayed in red and include keys for both .properties files.
Hi,
Yes it's bug, in this case files starts with cons* and PE thinks they in bundle.
But 2 editors mode is "bundle mode" and behaviour you described is normal in future version I'll address this issue.
TIA,
Dmitry
Hi,
Fixed in 1.5.1c by adding to prefix matching '.' or '_'.
TIA,
Dmitry
It's better, now, it remains a small bug:
write
a.b=foo
then
a=bar
then delete a.
a.b remains, but a's node is marked red.
Also: shouldn't be a way to show even a's value in the tree, when it has one?
3 minutes for my file in 1.5.1c
Do you get the same performance?
Amnon
"Dmitry Kashin" <no_mail@jetbrains.com> wrote in message
news:25646347.1082057562281.JavaMail.javamailuser@localhost...
>
>
It also takes 3 minutes when I change the delimiter.
From this finding it seems that the file is reparsed when one switches the
delimiter.
A couple of stray thoughts I am having regarding potential optimizations
that you may or may not already have:
1. Parsing could be in 2 phases - a HashMap of the identifiers as they
appear in the file (mapping of identifier to line number, value pairs to
cover duplicated identifiers), and a tree structure that will be created out
of the HashMap, thus allowing easier switching of delimiter.
2. HashMap and tree could be initialized with the number of lines in the
file. That will create some memory overhead (as there are empty lines and
comments) but will avoid excessive reallocation and garbage collection while
building the map or tree.
3. If you are reading the file character by character and parse it while
reading, it might be worth it to read the whole file and then work on it.
4. If you do the parsing in the background and update the tree view
gradually while allowing to edit the file in the same time, and then parse
the changes to a copy of the file before the editing was done, then update
the copy after you finish parsing the changes, even if it is still slow, it
will not hang IntelliJ for the parsing time and will allow smoother work.
A simple calculation shows that around 4500 entries take around 3 minutes
(180 seconds), i.e. 4500 / 180 = 25 entries are parsed per second, and that
seems slow for a Pentium 4 1.6GHz with 1GB of memory with 400MB unused).
Regards,
Amnon
"Amnon I. Govrin" <agovrin@freshwater.com> wrote in message
news:c5omn2$h9v$1@is.intellij.net...
>
>
>
>
>
Hi,
No it takes near 15-20 seconds to parse 400 kb file.
TIA,
Dmitry
Hi,
May be a.b not in all files? 'a' will be marked even if 'a.b' not everywhere present.
TIA,
Dmitry
Hi,
It works almost as you described and very strange so poor performance. In future versions I'll add more diagnostics. But even scrambled version of your file will be useful anyway.
TIA,
Dmitry