Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restructuring the code (Refactoring) #34

Open
stephano33 opened this issue Dec 22, 2017 · 3 comments
Open

Restructuring the code (Refactoring) #34

stephano33 opened this issue Dec 22, 2017 · 3 comments

Comments

@stephano33
Copy link

I love the library! I did an interesting demo that got quite some positive feedback. Will publish that.

The demo showed the performance problems and also that a 1 line change can make the library 22% faster. Now I look for more performance gains. However, there is one problem with the library that hinders the readability.

Rasterific does 4 different things:

  • Low level rendering
  • High level rendering API
  • Helper functions (e.g., "rectangle")
  • Coon (Gradient Mesh)

For me this is bad for readability and also from the standpoint of separation of concerns. I am probably going to rewrite a version of the library for myself to change that.

Minor things are copy/past code or code redundancy but this is a small detail.

@Twinside
Copy link
Owner

Hi, I'd like to see the code for the performance improvement, especially if it's just one line :].

I'm aware of a low hanging fruit on optimization for the 64 bit version of GHC, as some types used during rendering are tuned for 32bits, there is some quick win to do on memory usage.

For the "readability" bit, I don't know where you're going to, so I'll refrain to comment.

@stephano33
Copy link
Author

Hi,

Yes, I will give you the one line. But need to check again if it improves only my code or all code. Did you see the video of my snowflake benchmark? The video on Youtube?

If you give me a bit of feedback, I can make the speed improvements quicker.

type Container a = DList a
One question is, why did you use dynamic lists? Was it more because it was easy? Or is it good to have lazy evaluation for speed? Would a Vector be better for speed?

After that I also have another question on how to improve the edge sorting in sortEdgeSamples.

@stephano33
Copy link
Author

The one line improvement is truing on strict evaluation on the modulate that allocates most; for instance, -X Strict on Rasterize.hs can help. But as you see, this is just a trick to know that there is some problem with perhaps lazy evaluation. This is not a fix.

The next big step is where to do the changes so that the edges are sorted in parallel. Where would you do that change?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants