9 comments
Comment actions Permalink

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.

0
Comment actions Permalink

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

0
Comment actions Permalink

Hi,
Fixed in 1.5.1c by adding to prefix matching '.' or '_'.

TIA,
Dmitry

0
Comment actions Permalink

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?

0
Comment actions Permalink

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...

Bugs fixed:

>

  • Tree issues

  • Hang issue(I'm hope)

>

TIA,
Dmitry



0
Comment actions Permalink

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...

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...

Bugs fixed:

>

  • Tree issues

  • Hang issue(I'm hope)

>

TIA,
Dmitry

>
>


0
Comment actions Permalink

Hi,
No it takes near 15-20 seconds to parse 400 kb file.

TIA,
Dmitry

0
Comment actions Permalink

Hi,
May be a.b not in all files? 'a' will be marked even if 'a.b' not everywhere present.

TIA,
Dmitry

0
Comment actions Permalink

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

0

Please sign in to leave a comment.