Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
P
purr-data
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 269
    • Issues 269
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 16
    • Merge Requests 16
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Jonathan Wilkes
  • purr-data
  • Issues
  • #662

Closed
Open
Opened Jul 26, 2020 by Jonathan Wilkes@jwilkesMaintainer

[list store] not optimal for building gigantic messages

If you try to accumulate a large list with [list store], reallocation time becomes a major factor on Windows.

Can easily improve realloc times by overallocating using a simple doubling algorithm.

There's already a related "quick-and-dirty" algorithm like that in unpost_printhook to fill in for C++ iostream from matju's original C++ implementation. So we probably want to put an interface in m_memory.c for general use.

However, we'd need to be careful to document this interface as inappropriate for realtime computation. While it can vastly improve average performance it doesn't guarantee worst-case performance. (And in fact better average perf can hide worst-case perf from the user, which is a strange but very real usability problem in soft realtime environments like this.)

In fact, we may consider adding something like [list storeupto 100] to initialize max size to 100 and error out above that. This would avoid realloc altogether and could be realtime safe if we handle gpointers efficiently.

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: jwilkes/purr-data#662