---
# System prepended metadata

title: 2022-05-08 Weekly Meeting
tags: [weekly-meeting]

---

# 2022-05-08 Weekly Meeting

###### tags: `weekly-meeting`

### Topics:

#### Issues



#### Servers and optimizations

- Looking at current situation
- https://gitlab.com/veloren/veloren/-/issues/1533
- https://gitlab.com/veloren/veloren/-/issues/1534
- https://gitlab.com/veloren/veloren/-/issues/1535
- https://gitlab.com/veloren/veloren/-/issues/1536

- Analysis
    - Currently, we can see that although we are running high on tick times, we're not pinning CPUs. We are seeing that our cores are running at around 50% of their full potential.
    - With more powerful servers, we are seeing efficiency drop further
    - There are dimishing returns that upgrading to better hardware won't fix
    - Specific jobs
        - Buffs taking up a lot of time at the beginning of a tick

- Discussion items
    - (Avi) w.r.t. #1535, once serialization of terrain is deferred to slowjobs and no longer blocks the main system ticks, do we have some notion of how much headroom we have for slowjobs? (e.g. the CSG JIT would speed up chunk generation, which currently happens on the slowjobs threadpool, which may not currently be a bottleneck, but speeding that up might make more room for other slowjobs?)
    - (zesterer) Might be worth clarifying that "efficiency" here means "proportion of time that the cores spend doing actually useful work vs waiting on another core"
    - (zesterer) I feel like we should take a look at system dependencies to see whether there is ECS data that goes unused or can be replaced with stale data to reduce data dependencies
    - (zesterer) One way physics could be improved a lot is a simple AABB check for airships before doing full physics calcs. IIRC we don't do any sort of spatial culling of voxel entity collisions, and the collision resolution has a lot of complex stuff going on (multiple matrix transforms, etc.)
    - (zesterer) Oh! Outcomes! They could be parallelise a lot. We should use EventBus instead, but we currently use a Vec\<Outcome>. That might reduce data dependencies a lot

- Questions
    - Why do we have to do everything before we consider the tick over?
        - For example, do we have to send
    - What are our goals?
        - Many servers with <100 players, or 1000 players on a server?

- Action items
    - Could we better document how a frame breaks down into tasks, and what is taking time on the main thread?
        - Since the main thread is the single area that matters for how fast ticks can finish (I might be wrong), it would be good to have it broken down
        - There are already some docs for this
    - Look into actions

## Next week leads

Lead: 
Call for Review!: 
Issues (limit 7): 
Minutes: Angel

### Todo agenda: