ZIm/docs/src/development.md
Finn Evers 26ba6e7e00
editor: Improve minimap performance (#33067)
This PR aims to improve the minimap performace. This is primarily
achieved by disabling/removing stuff that is not shown in the minimal as
well as by assuring the display map is not updated during minimap
prepaint.

This should already be much better in parts, as the block map as well as
the fold map will be less frequently updated due to the minimap
prepainting (optimally, they should never be, but I think we're not
quite there yet).
For this, I had to remove block rendering support for the minimap, which
is not as bad as it sounds: Practically, we were currently not rendering
most blocks anyway, there were issues due to this (e.g. scrolling any
visible block offscreen in the main editor causes scroll jumps
currently) and in the long run, the minimap will most likely need its
own block map or a different approach anyway. The existing
implementation caused resizes to occur very frequently for practically
no benefit. Can pull this out into a separate PR if requested, most
likely makes the other changes here easier to discuss.

This is WIP as we are still hitting some code path here we definitely
should not be hitting. E.g. there seems to be a rerender roughly every
second if the window is unfocused but visible which does not happen when
the minimap is disabled.

While this primarily focuses on the minimap, it also touches a few other
small parts not related to the minimap where I noticed we were doing too
much stuff during prepaint. Happy for any feedback there aswell.

Putting this up here already so we have a place to discuss the changes
early if needed.

Release Notes:

- Improved performance with the minimap enabled.
- Fixed an issue where interacting with blocks in the editor would
sometimes not properly work with the minimap enabled.
2025-07-15 00:29:27 +03:00

3 KiB

Developing Zed

See the platform-specific instructions for building Zed from source:

If you'd like to develop collaboration features, additionally see:

Keychain access

Zed stores secrets in the system keychain.

However, when running a development build of Zed on macOS (and perhaps other platforms) trying to access the keychain results in a lot of keychain prompts that require entering your password over and over.

On macOS this is caused by the development build not having a stable identity. Even if you choose the "Always Allow" option, the OS will still prompt you for your password again the next time something changes in the binary.

This quickly becomes annoying and impedes development speed.

That is why, by default, when running a development build of Zed an alternative credential provider is used in order to bypass the system keychain.

Note: This is only the case for development builds. For all non-development release channels the system keychain is always used.

If you need to test something out using the real system keychain in a development build, run Zed with the following environment variable set:

ZED_DEVELOPMENT_USE_KEYCHAIN=1

Performance Measurements

Zed includes a frame time measurement system that can be used to profile how long it takes to render each frame. This is particularly useful when comparing rendering performance between different versions or when optimizing frame rendering code.

Using ZED_MEASUREMENTS

To enable performance measurements, set the ZED_MEASUREMENTS environment variable:

export ZED_MEASUREMENTS=1

When enabled, Zed will print frame rendering timing information to stderr, showing how long each frame takes to render.

Performance Comparison Workflow

Here's a typical workflow for comparing frame rendering performance between different versions:

  1. Enable measurements:

    export ZED_MEASUREMENTS=1
    
  2. Test the first version:

    • Checkout the commit you want to measure
    • Run Zed in release mode and use it for 5-10 seconds: cargo run --release &> version-a
  3. Test the second version:

    • Checkout another commit you want to compare
    • Run Zed in release mode and use it for 5-10 seconds: cargo run --release &> version-b
  4. Generate comparison:

    script/histogram version-a version-b
    

The script/histogram tool can accept as many measurement files as you like and will generate a histogram visualization comparing the frame rendering performance data between the provided versions.