Post from Jul 24, 2026
Cut down the startup time of Easy Diffusion by 4 seconds on warm start, and atleast 10 seconds on cold start. Removed a couple of unnecessary imports and ran a few things in parallel. Released this to the beta channel.
Cut down the startup time of Easy Diffusion by 4 seconds on warm start, and atleast 10 seconds on cold start. Removed a couple of unnecessary imports and ran a few things in parallel. Released this to the beta channel.
Upgraded stable-diffusion.cpp in Easy Diffusion (and sdkit) to the latest version. This adds support for two new models: Lens and PiD, along with a bunch of bug fixes (for e.g. Chroma rendering has been fixed). It also brings back --diffusion-fa by default, which speeds up rendering. And Chroma seems to be rendering faster than before.
Just completed another round of fixing support issues in Easy Diffusion. Today's evidence continues to convince me to move Easy Diffusion away from the Python ecosystem for AI inference on end-user PCs. And definitely to stay away from conda, it's so leaky. Both are excellent in their own right (especially for training and research), but I don't think they make sense for end-user inference.
Got Easy Diffusion v4 working on Apple and Intel Macs. The performance difference ratio (vs ED v3) is similar to the ratio on Windows (with CUDA) and other deployment targets. So that indicates optimization opportunities in sd.cpp. It's currently about 1.5x slower than diffusers-based Stable Diffusion.
Started the long-pending rewrite of Easy Diffusion's server code. v4 intends to replace the Python (and PyTorch) based server with a simple C++ version. The reason for rewriting the server in C++ is to achieve sub-second startup time for the UI, and to reduce the download size (won't need to distribute Python along with Easy Diffusion) or mess with conda/venv etc. And it's also something that I want to do for personal taste, i.e. de-bloating what doesn't need to be bloated.
For Z-Image, the performance of the stock version of chromaForge is poorer than sd.cpp's. Mainly because chromaForge isn't able to run the smaller gguf quantized models that sd.cpp is able to run (chromaForge fails with the errors that I was fixing yesterday).
Worked on fixing Z-Image support in ED's fork of chromaForge (a fork of Forge WebUI). Fixed a number of integration issues. It's now crashing on a matrix multiplication error, which looks like an incorrectly transposed matrix (mostly due to reading the weights in the wrong order).
Wrote a simple script to convert ONNX to GGML. It auto-generates C++ code that calls the corresponding ggml functions (for each ONNX operator). This file can then be compiled and run like a normal C++ ggml program, and will produce the same results as the original model in PyTorch.
Cleared the backlog of stale issues on ED's github repo. This brought down the number of open issues from ~350 to 74.