• @nutomicMA
    link
    5
    edit-2
    4 years ago

    This week I was mainly working on reorganizing the backend, and splitting it into different cargo workspaces. I mainly did that with the goal of speeding up compilation time, but unfortunately that wasnt successful, its exactly as slow as before (3m 40s for a clean build on my Ryzen 5 2600). The reason is that Diesel, our library for interacting with the database is completely dominating compilation time. There is one thing we could do to, but it would require another database rework.

    For visualization, the long bar in the graph below is Diesel, and Lemmy itself can only be compiled once that is finished (which takes around 95s for me).

    Other than that, we approved new rules for the Lemmy Council, which are much clearer and easier to understand (PR for it is here).

      • @nutomicMA
        link
        24 years ago

        There are a many use cases where the time for a clean build matters:

        • a new contributor compiles the project for the first time
        • continuous integration often builds everything from scratch
        • docker builds dont have good dependency caching

        Besides, I can sometimes see Diesel being rebuilt in incremental builds for no reason at all, and it sucks waiting almost two minutes for that.

    • @nutomicMA
      link
      24 years ago

      Actually I wanted to write a bit more about the workspaces, but forgot while taking the screenshot. Besides faster compilation, the workspaces are also useful for splitting a project into smaller units that are easier to manage. This means someone can now work on the database without affecting someone who works in the activitypub code (as long as the public interface doesnt change). It also gets much easier to see how the code should be split up, for example I noticed that it doesnt make sense encoding and decoding jwt tokens in the database, so I moved it out of there.