optimize-all-path-go

[nevermore3]

What type of PR is this?

• bug
• feature
• enhancement

What problem(s) does this PR solve?

Issue(s) number:

close https://github.com/vesoft-inc/nebula-ent/issues/2725

Description:

allPath:
1、In the allpath operator, the intermediate path uses the alternate of vertex and edge (for example [src, [e1, v1,e2,v2,e3], dst]) to represent the path
2、The copy constructor and assignment constructor of the VERTEX and the EDGE  are shallow copies
3、Construct paths base on  adjacency lists using multiple threads

Therefore, when constructing a new path, a large number of copies of vertex and edge are involved. reference count in  VERTEX and EDGE becomes a performance bottleneck

Some improvements blow:
1、Use the new structure NPath to save intermediate paths
    struct NPath {
      NPath* p;
      const Value& vertex;
      const Value& edge;
    }
   This can avoid copying vertex and edge each time a new path is generated
  2、Use threadLocalPtr to save the NPath structure generated inside each thread, reducing the time taken to release memory
BEFOR
(root@nebula) [sf100]>  FIND ALL PATH FROM 1129 TO 30786325832215 OVER KNOWS YIELD path AS p | YIELD count(*);
+----------+
| count(*) |
+----------+
| 112808   |
+----------+
Got 1 rows (time spent 18277713/18271423 us)
NOW
(root@nebula) [sf100]>  FIND ALL PATH FROM 1129 TO 30786325832215 OVER KNOWS YIELD path AS p|yield count(*)
+----------+
| count(*) |
+----------+
| 112808   |
+----------+
Got 1 rows (time spent 2572926/2574018 us)

Go planner

For the scenario of GO n STEPS FROM xxx OVER edge YIELD DISTINCT edge._dst,
use the new execution plan alone, and only obtain the destination point through the getDstbysrc operator

How do you solve it?

Special notes for your reviewer, ex. impact of this fix, design document, etc:

Checklist:

Tests:

• Unit test(positive and negative cases)
• Function test
• Performance test
• N/A

Affects:

• Documentation affected (Please add the label if documentation needs to be modified.)
• Incompatibility (If it breaks the compatibility, please describe it and add the label.）
• If it's needed to cherry-pick (If cherry-pick to some branches is required, please label the destination version(s).)
• Performance impacted: Consumes more CPU/Memory

Release notes:

Please confirm whether to be reflected in release notes and how to describe:

ex. Fixed the bug .....

[yixinglu]

why need to reverse the list?

[nevermore3]

when recursively parsing vertex and edge through NPath, the order is reversed compared to the topology of the path