sonar-openedge icon indicating copy to clipboard operation
sonar-openedge copied to clipboard

PDSOE + OEDT + Sonarlint xref rules performance issue

Open cverbiest opened this issue 5 years ago • 3 comments

@gquerret, @lneumeier I'm not sure what is the best place to post this as this issues involves multiple parties, not sure who from Progress I could include in this query.

Issue : full build performance

A full compile using OEDT builder is slow, one of the culprits is xref file generation. xref for the projects in my workspace totals to +8000 files resulting in almost 10 GB of files.

I have xref enabled only for the on-the-fly sonarlint, I don't really need it for a full build.

It would be nice if there was some way that xref would only be generated for a compile on save and not for a compile during build.

I'm also thinking of moving xref files to a ramdisk but then it would be nice if sonarlint could, optionally, delete the files one it has done with processing. otherwise I'd need a 10GB ramdisk

Not sure what can be done or who can do someting.

cverbiest avatar Jul 09 '19 10:07 cverbiest

A better file format for XREF would be good, XML XREF has always been slow to be generated, and slower to be parsed (on top of having to deal with invalid XML files). And standard text XREF is inconsistent, leading to invalid behavior. That said, deleting XREF files in SonarLint can be done as part of a feature branch to verify it doesn't break too many things.

gquerret avatar Jul 09 '19 20:07 gquerret

As Gilles have mentioned, the performance issue is related to XREF XML file generation. (https://github.com/Riverside-Software/pct/issues/333#issuecomment-452684014)

For OEDT it would be possible to generate a XREF-XML only for files that are opened in an editor. However, this would mean, that you have to save/compile the editor file first, to get a proper Sonarlint evaluation. This is something I don't quite like. I think, that it is up to Progress to provide a better performance or a faster alternative to XREF-XML.

lneumeier avatar Jul 11 '19 07:07 lneumeier

@lneumeier I totally agree Progress should provide better performance and a better compiler. Sonar-openedge & OEDT are two great products helping us to cope with some of the shortcomings of PDSOE / ABL . I was just asking if there were, easy, options to improve this. I knew it was a long shot, and not really an issue of either product.

cverbiest avatar Jul 11 '19 07:07 cverbiest

I tried to implement your idea of deleting the XML file after being processed by SonarLint, but I ran into too many issues. PDSOE probably keeps the XML file opened after it is generated, and deleting the file often takes a couple seconds (sometimes more than 10 or 15...) so the UX is really bad. I'll close the issue as nothing can really be done without the involvement of Progress.

gquerret avatar Jan 15 '24 16:01 gquerret