Benchmark and Improve GDS Database Loading #27
Labels
No Milestone
No Assignees
1 Participants
Notifications
Due Date
Dependencies
No dependencies set.
Reference: mhu/gds-render#27
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
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.
"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.
Closed. Performance seems okay for the time...