kaby76
Slow
ClangSerializer takes 45 s to create an AST for peimage.cpp of Net Core. To parse the AST, PiggyTool takes about 30 s. These times are pretty slow. There are likely several issues, but the likely problem is just that the AST file is 158 MB. Patterns include limits, so I don't need the whole tree from the serializer. There should be a smaller representation of the AST.
After opening VS2017 IDE on a project that uses Piggy, a Rebuild performs not one, but two invocations of Piggy, which also accounts for some of the terrible performance. I'm not sure why it is invoking this twice. It could be that the first performs a build to determine dependencies? However, I don't know why it would then proceed with the second invocation.
Open a .sln file, then rebuild, then close .sln. Then, attach to the MSBuild.exe process under the VS process tree, as VS does not destroy the instance, and set a breakpoint at Execute() in Piggy.dll source code. Open the .sln file. MSBuild calls to build the solution twice. This is completely unacceptable. VS should not be doing anything until I say "Build".
To boot, the "Build Output" window is empty after opening the .sln file. Completely unacceptable MS!
I've determined that one problem here is due to a design-time build occurring at the time of the opening of a .sln file (https://developercommunity.visualstudio.com/content/problem/449863/opening-a-project-performs-itaskexecute-i-dont-kno.html). The solution involves distinguishing between normal builds and design-time builds, and passing that to the tool. The fix will be in the next release.
V1.0.14 fixes the build problem. It also likely fixes the problem noted elsewhere where it cannot write to a file because it is locked...due to multiple invocations of piggy builds. I am working on the large ast files next, along with a linux build.
You may also want to consider moving your string parsing over to Span and Slice. Would be much faster and use less memory. Just a thought.
Will consider span/slice<>. But, it's clear the AST is huge for a typical C++ file in NET Core. Generating the AST should be limited to the scope specified in a pattern. The authors of Coccinelle (a C program transformational system) came to the same conclusion: "A key observation is that an individual Linux kernel file typically addresses a problem at a given level of abstraction, while references to other files, via #include or function calls, typically move to a lower level of abstraction. Thus, the contents of header files and called functions may be less relevant for collateral evolutions. Based on the above observation, by default, Coccinelle processes only .c files, includes only header files that are located in the same directory as the .c file or that have the same name as the .c file, and does not perform interprocedural analysis."