SWAT-engineering / SWAT-engineering/java-watch
Enqueue collections of events instead of individual events in `MacWatchKey`?
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 1
- Forks
- 0
- Avg merge
- 14h 40m
- Merged PRs (30d)
- 1
Description
Events are enqueued to the list of pending events individually in MacWatchKey. It might be faster to, before enqueueing, collect all events that are available at that point (but not yet enqueued) and enqueue the collection. Note: This is an optimization of which the need/effectiveness currently is unclear.
Further background:
- Original comment
- In a previous version of the library, the poller used to submit a separate job to the thread pool for each incoming event. This didn't work well in situations with many events (e.g., in the torture tests). Currently, instead, the poller collects multiple events in each job. This feature of the poller might be strengthened by using "pre-collection" as suggested in this issue (or it might not; that's to be found out).
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading MacWatchKey and the poller’s existing event-collection behavior. Run the torture tests to understand the high-event-rate case described in the issue, then measure whether pre-collecting available events improves it. Done means the optimization’s effect is established and any resulting change is validated against those tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- operating-systems, performance
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 28/100