Benchmark and Improve GDS Database Loading #27

New Issue

mhu · 2019-09-13T18:01:22+02:00

mhu commented

2019-09-13 18:01:22 +02:00

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.

mhu commented

2019-09-13 22:30:34 +02:00

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.

mhu commented

2019-09-13 22:32:45 +02:00

No description provided.

callgrind-stripped.png

132 KiB

callgrind-rendering.png

3.3 MiB

callgrind.png

2.9 MiB

mhu commented

2019-09-19 21:59:49 +02:00

"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.

mhu commented

2019-10-02 18:50:26 +02:00

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.