Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • T trappy
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 19
    • Issues 19
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 6
    • Merge requests 6
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Tooling
  • trappy
  • Issues
  • #257
Closed
Open
Created Jun 27, 2017 by Darryl Green@Darryl.GreenOwner

Explore possibility of time-based tests for trappy

Created by: joelagnel

Recently lot of speed up related patches have posted. It would be good to be able to test and make sure these improvements aren't regressed in the future. One concern is that its hardware dependent and is hard to measure. This issue is created to discuss this. I think we can still come up with a worst-case upper bound experimentally and set that as the expectation. If we are threading trappy in the future, then we can perhaps limit the number of threads so that the number of cores that the test is run on doesn't change or artificially make a failure result as passed (as a false-positive). (CC @derkling)

Assignee
Assign to
Time tracking