Open usedbytes opened 6 years ago
Any idea on what the bottleneck might be? Comparable performance would be a long-term goal.
Thanks for the benchmark comparison. I need to make more test but, I feel it comes from the fill operation. I didn't work a lot on performance. The package I use for this is https://github.com/golang/freetype/raster
Yes, it does seem to be the raster code (*RGBAPainter).Paint
Flat | Flat% | Sum% | Cum | Cum% | Name | Inlined? |
---|---|---|---|---|---|---|
2.20s | 95.24% | 95.24% | 2.20s | 95.24% | github.com/golang/freetype/raster.(*RGBAPainter).Paint | |
0.04s | 1.73% | 96.97% | 0.04s | 1.73% | github.com/golang/freetype/raster.(*Rasterizer).findCell | |
0.04s | 1.73% | 98.70% | 2.24s | 96.97% | github.com/golang/freetype/raster.(*Rasterizer).Rasterize | |
0.01s | 0.43% | 99.13% | 0.05s | 2.16% | github.com/golang/freetype/raster.(*Rasterizer).saveCell | |
0.01s | 0.43% | 99.57% | 0.06s | 2.60% | github.com/golang/freetype/raster.(*Rasterizer).setCell | |
0 | 0.00% | 99.57% | 2.30s | 99.57% | github.com/llgcode/draw2d/draw2dimg.(*GraphicContext).FillStroke | |
0 | 0.00% | 99.57% | 0.06s | 2.60% | github.com/llgcode/draw2d/draw2dimg.(*FtLineBuilder).LineTo | |
0 | 0.00% | 99.57% | 0.06s | 2.60% | github.com/llgcode/draw2d/draw2dbase.Transformer.LineTo | |
0 | 0.00% | 99.57% | 0.06s | 2.60% | github.com/llgcode/draw2d/draw2dbase.Flatten | |
0 | 0.00% | 99.57% | 0.03s | 1.30% | github.com/llgcode/draw2d/draw2dbase.DemuxFlattener.LineTo | |
0 | 0.00% | 99.57% | 2.24s | 96.97% | github.com/llgcode/draw2d/draw2dimg.(*GraphicContext).paint | |
0 | 0.00% | 99.57% | 0.06s | 2.60% | github.com/llgcode/draw2d/draw2dbase.(*Transformer).LineTo | |
0 | 0.00% | 99.57% | 0.03s | 1.30% | github.com/llgcode/draw2d/draw2dbase.(*LineStroker).End | |
0 | 0.00% | 99.57% | 0.03s | 1.30% | github.com/llgcode/draw2d/draw2dbase.(*DemuxFlattener).LineTo | |
0 | 0.00% | 99.57% | 0.03s | 1.30% | github.com/llgcode/draw2d/draw2dbase.(*DemuxFlattener).End | |
0 | 0.00% | 99.57% | 0.06s | 2.60% | github.com/golang/freetype/raster.(*Rasterizer).Add1 | |
0 | 0.00% | 99.57% | 0.06s | 2.60% | github.com/llgcode/draw2d/draw2dimg.FtLineBuilder.LineTo | |
0 | 0.00% | 99.57% | 2.30s | 99.57% | github.com/usedbytes/drawbench.BenchmarkDraw2D | |
0 | 0.00% | 99.57% | 2.30s | 99.57% | testing.(*B).launch | |
0 | 0.00% | 99.57% | 2.30s | 99.57% | testing.(*B).runN | |
0 | 0.00% | 99.57% | 0.03s | 1.30% | github.com/llgcode/draw2d/draw2dbase.DemuxFlattener.End |
Collected using the testing package's built-in profiling:
$ go test -cpuprofile cpu.prof -bench .
goos: linux
goarch: amd64
pkg: github.com/usedbytes/drawbench
BenchmarkDraw2D-4 1000 2092810 ns/op
BenchmarkCairo-4 30000 44773 ns/op
PASS
ok github.com/usedbytes/drawbench 4.314s
$ go tool pprof -http=:8000 cpu.prof
The Cairo counterparts (cairo_stroke
and cairo_fill
) take a similar percentage of the time, but are faster in absolute terms. I imagine they're just much more highly optimised.
Perhaps this doesn't qualify as an issue per-se, but I wanted to use draw2d as the renderer in my program (instead of Cairo). However, even in simple cases, draw2dimg performs at least 10-30x worse than the equivalent Cairo code via cgo.
Maybe I'm doing something wrong? (I hope so)
Simple benchmark test below draws filled squares with an outline, performing ~30x worse on draw2d than Cairo. When the drawn surface is 1:1 blitted to another surface, the gap closes to ~10x
Results:
The README says that draw2d is a pure-go alternative to Cairo, but unfortunately the performance difference is too high for my use-case.