Benchmark and Improve GDS Database Loading #27

Closed
opened 2019-09-13 18:01:22 +02:00 by mhu · 4 comments
Owner

For bigger Chip layouts, database loadingmay take several seconds. This is very annoying. Especially when you only want to render a small component in this library.

Analyzing: Benchmark the parse_gds_from_file() function using perf, gprof, systicks etc.

Already known possible speed killers:

  • Allocation of memory using malloc() for every single structure.
  • Reading very small chunks from file.
For bigger Chip layouts, database loadingmay take several seconds. This is very annoying. Especially when you only want to render a small component in this library. Analyzing: Benchmark the parse_gds_from_file() function using perf, gprof, systicks etc. Already known possible speed killers: * Allocation of memory using malloc() for every single structure. * Reading very small chunks from file.
Author
Owner

According to several callgrind runs, reading very small chunks from file is not an issue (see callgrind-stripped -> fread -> 1.08% execution time). malloc() itself needs only 2% directly. Therefore, this is also not a big speed factor.

The parse_gds_from_file() functions needs about 50% execution time in the conducted testrun. The majority of this time is needed in g_list_append's internally used function g_list_last.

Implementing a faster storage for the vertices will therefore be a major enhancement.

THis can e.g. be achieved by appending to the start of the list. This makes the time consuming g_list_last() calls unnecessary. Another way would be implementing a custom list which stores the last element in the prev pinter of the first element. Sort of a ring like structure.

According to several callgrind runs, reading very small chunks from file is not an issue (see callgrind-stripped -> fread -> 1.08% execution time). malloc() itself needs only 2% directly. Therefore, this is also not a big speed factor. The parse_gds_from_file() functions needs about 50% execution time in the conducted testrun. The majority of this time is needed in g_list_append's internally used function g_list_last. Implementing a faster storage for the vertices will therefore be a major enhancement. THis can e.g. be achieved by appending to the start of the list. This makes the time consuming g_list_last() calls unnecessary. Another way would be implementing a custom list which stores the last element in the prev pinter of the first element. Sort of a ring like structure.
Author
Owner
Author
Owner

"Fixed" in cfc156c1c0 by the above described fix.

It turned out to be more relevant to modify the list containing the graphic objects instead of the vertices itself because there are much more grpahics in a cell than vertices in a typical graphic.

Issue will be left open for further modifications of the vertex lists and other small stuff.

"Fixed" in cfc156c1c0f8b06dc6080c6a7d9a81875ab8006b by the above described fix. It turned out to be more relevant to modify the list containing the graphic objects instead of the vertices itself because there are much more grpahics in a cell than vertices in a typical graphic. Issue will be left open for further modifications of the vertex lists and other small stuff.
Author
Owner

Closed. Performance seems okay for the time...

Closed. Performance seems okay for the time...
mhu closed this issue 2019-10-02 18:50:26 +02:00
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

0001-01-01

Dependencies

No dependencies set.

Reference: mhu/gds-render#27
No description provided.