Context
Swan has containers ("components") which store path data. A replacement for the swan_path data type is needed which is more memory efficient, and offers good runtime performance characteristics.
The current swan_path implementation is struct swan_path : std::array<char, ((MAX_PATH - 1) * 4) + 1>, an array of characters which holds up to the theoretical maximum length in bytes of a UTF-8 path which meets the MAX_PATH constraint in Windows.
The issue with this implementation is it always occupies 1037 bytes of memory, but very rarely uses all of it. Most paths are much shorter than MAX_PATH, the common case being <= 50 codepoints. To put this into perspective, if the average path is 50 ASCII characters + 1 NUL, then the swan_path data type wastes about 9.4MB per 10,000 objects. This is significant for components which store many elements, each containing one or sometimes multiple swan_path.
The main goal is to rework the swan_path implementation for the listed components and eliminate this memory wastage without hurting performance in key areas.
Constraints
Each component has some constraints imposed based on how the data in the containers is used:
- ImGuiListClipper constraint: requires container elements to be same size, no dynamic element sizes allowed. This is because list clipper demands that the container support random access, as iteration of the container does not always begin at the first element.
Constraints specific to a component are detailed in the dedicated section further down.
In general, the replacement of the underlying type for swan_path must:
- Provide member function
char *data() noexcept
- Provide the ability to query its length in O(1) time, not O(n)
Components
| Component |
Current container type |
ImGuiListClipper constraint? |
explorer_window::cwd_entries |
std::vector |
Y |
g_file_op_cmd_buf |
std::vector |
Y |
g_pins |
std::vector |
Y |
g_recent_files |
circular_buffer |
Y |
g_completed_file_ops |
circular_buffer |
Y |
explorer_window::wd_history |
circular_buffer |
N |
explorer_window::cwd_entries
TODO
explorer_window::wd_history
TODO
g_file_op_cmd_buf
TODO
g_pins
TODO
g_recent_files
TODO
g_completed_file_ops
TODO
Context
Swan has containers ("components") which store path data. A replacement for the
swan_pathdata type is needed which is more memory efficient, and offers good runtime performance characteristics.The current
swan_pathimplementation isstruct swan_path : std::array<char, ((MAX_PATH - 1) * 4) + 1>, an array of characters which holds up to the theoretical maximum length in bytes of a UTF-8 path which meets the MAX_PATH constraint in Windows.The issue with this implementation is it always occupies 1037 bytes of memory, but very rarely uses all of it. Most paths are much shorter than MAX_PATH, the common case being <= 50 codepoints. To put this into perspective, if the average path is 50 ASCII characters + 1 NUL, then the
swan_pathdata type wastes about 9.4MB per 10,000 objects. This is significant for components which store many elements, each containing one or sometimes multipleswan_path.The main goal is to rework the
swan_pathimplementation for the listed components and eliminate this memory wastage without hurting performance in key areas.Constraints
Each component has some constraints imposed based on how the data in the containers is used:
Constraints specific to a component are detailed in the dedicated section further down.
In general, the replacement of the underlying type for
swan_pathmust:char *data() noexceptComponents
explorer_window::cwd_entriesstd::vectorg_file_op_cmd_bufstd::vectorg_pinsstd::vectorg_recent_filescircular_bufferg_completed_file_opscircular_bufferexplorer_window::wd_historycircular_bufferexplorer_window::cwd_entries
TODO
explorer_window::wd_history
TODO
g_file_op_cmd_buf
TODO
g_pins
TODO
g_recent_files
TODO
g_completed_file_ops
TODO