Skip to content

Instantly share code, notes, and snippets.

@antonfirsov

antonfirsov/ImageSharpStuff2017.MD

Last active January 5, 2017 01:35
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save antonfirsov/fa6b93048d414aee4b644a6dd5f5932c to your computer and use it in GitHub Desktop.
Save antonfirsov/fa6b93048d414aee4b644a6dd5f5932c to your computer and use it in GitHub Desktop.
Download ZIP
Raw
ImageSharpStuff2017.MD

Gif Encoder

I did not know that System.Drawing is a cheetah at gif, but let it be their problem! :) We need to find a better baseline then! What was made me to do this benchmark was seeing the OctreeeQuantizer's code. It's is very allocation-heavy. I think we can make a great improvement simply by doing a DOD refactor on the Octree class. It could be a very useful OOP vs DOD case study! However ... The numbers make me think there might be also an algorithmical issue. Is the whole algorithm running in O(PixelCount)? Does the tree have a depth limit? I can also pick this task if you want! :)

VS2017 and Span:

I think @dlemstra is concerned about VS2017. For me it's OK, we need to switch sooner or later anyway. But I'm also fine with a custom NuGet package. I already managed to pack the latest System.Runtime.CompilerServices.Unsafe with different class name to avoid collision with the official class. If we decide to stick with VS2015 for now, I can build a custom System.Memory package for the project!

ImageSharp performance and "market" position

I also think TPixel rocks in many ways! There are many issues in the "minimalistic" thread which could be solved!

GC + LOH??

ArrayPool !! // ... and IDisposable :(

I strongly believe, it's possible to achieve competitive results in .NET, but it comes with a high price:

  • We need DOD (more value types, stack-only arrays, etc.)
  • We need to refactor lot's of per-pixel operations into batched ones. Calling virtual functions for each pixel in an image is ... Brrrrrrhhh OMG!
  • We need metaprogramming tools as a replacement for classic OOP abstractions (T4 or Roslyn)

All in all: We have to jump from the classic OOP-purist .NET we had taught for years into the new era of stackful/structful "systems" .NET, pioneered by Joe Duffy. Becoming members of the crazy 0.001%.

It's very interesting to me: how much do you want to pay of this price in ImageSharp? Can we clarify the development priorities? You had many users of ImageProcessor, so you should know a lot about them. Do you think performance is a key concern that's worth the hard efforts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment