Auto Block commenting closing hangs or it is too slow with big SV files
Status: Beta
Brought to you by:
mballance
Menu
▾
▴
#466 Auto Block commenting closing hangs or it is too slow with big SV files
Dear SVEditor team,
Lets assume you have a big Systemverilog file with around 7000 lines of code. In those cases, SVEditor auto block commenting feature is too slow and it seems to hang eclipse.
The Auto block commenting feature i speak about works in the following way.
Below an example, assume a code inside this big 7000 line code file.
task body; //pnio_ethercat_tb_req_sequence_p1
automatic int test;
automatic int test2;
....
end task
Now you want to comment two lines using the block-comment operator / .... /. So you open the block comment with "/" and at the end of the last line you want to comment you press ENTER.
Now SVEditor will parse the whole code and insert automatically the closing block comment operator after your ENTER "/"
task body; //pnio_ethercat_tb_req_sequence_p1
/*automatic int test;
automatic int test2; (PRESS ENTER HERE) //after a very long long time the closing */ will appear
....
end task
This only is noticeable with long files, that is, files that have many lines of code. This problem is very annoying because it blocks you for minutes,it makes eclipse unusable.
A fast solution would be to provide a configuration parameter where you can disable this auto block comment closing feature in SVEditor. Normally you press the ENTER accidentally and this feature is triggered. The other solution would be to increase the speed for that parsing. :)
That problem was not so noticeable in previous problems so please could you correct that or offer a work around?
Looking forward an answer
Thanks
Best regards,
Jonathan
Fixed in 1.9.5
Looks this is an unintended consequence of having SVE attempt to add a NDOC compliant header to a given module / interface etc. The code should trigger only on a /*<ENTER> sequence, instead it is triggering on /<anycombination of="" characters=""><ENTER>.
While this fix will fix the issue described above, there is an inherent performance issue which is higlighted where the generation of a NDOCS header is taking too long on large files.
I expect that if you take the example below (modified from the one above) that you will see the same performance currently seen, except now it will do something sensible rather than just adding a trailing */
/**<ENTER> task body; //pnio_ethercat_tb_req_sequence_p1 automatic int test; automatic int test2; .... end taskSteven, did you get a sense of what was taking all the time? Are we
scanning through lots of text? Reparsing the whole file (when, perhaps, we
shouldn't)? Something else?
On Fri, Feb 3, 2017 at 2:53 PM, StevenAZ stevenaz@users.sf.net wrote:
Johnathan,
How is the performance if you Ctrl+A, Ctrl+Shift+/? on a really large file?
Matt,
I will take a look. My guess is that I am polling the DB for all instances in the current file, but I don't remember what I did off hand to be sure of that.
Steven
The code works as follows:
1. Decide that user is possibly trying to add a NDOC comment above a module/program/task (triggered by /**<ENTER>
2. Figure out what line I am on
2. Iterate through each element in the current file, and all their children, childrens children and so on (which on a 7k line file with a reasonable number of assign statements could take ages) checking to see if the item is a module, program block that is likely to need a NDOC comment, else go to next child.
3. Check to see if the item is on the current line (massive issue here because the DB could be out of date). If so, go ahead and generate a NDOC comment, return allowing SVE to insert the NDOC comment.
4. I do this 3 times, hoping I run across a line match (which is an easy fix) and will cut the iteration down by two thirds. (this is absolutenly a hack)
Argueably the file should be re-parsed when the "SVMultiLineCommentAutoIndent" triggers and we are starting a block comment with /**, allowing "pin-point" accuracy and not requiring the guess work I am doing.
This could also possibly be sped up if the way I am iterating through the DB is inefficient, which it may be to be honest.
Natural Docs adder updated to be more efficient all in all.
Dear SVEditor developers,
Sorry for the late answer. I was sick.
I have tried Ctrl+A, Ctrl+Shift+/ and the performance was so bad as before.
However, i tried Ctrl+Shift+/ over a small ammount of code i have selected and that was very fast. (Almost unnoticeable).
From these results, i guess that the automatic parsing/commenting that i described before is doing a parsing of the whole file when it shouldnt or ,at least, not an intelligent search for the previous opening
/**marker.That is the reason why selecting the code and doing Ctrl+Shift+/ is being faster.
Could you investigate on that?
Best regards,
Jonathan