Performance and Memory improvement for loops

[mgreter]

Added some performance improvements for some loops. Currently libsass allocates a new variable in a for loop for each iteration. This is not the best strategy, as it costs us performance and memory (since all these allocations would not be freed until context is freed). I have added two different optimizations and we should try to find more spots which could optimize the same way.

• Added Memory Manger to Environment, so stuff that really only lives in a certain Env can be re-claimed when the Environment goes out of scope (mostly variables).
• Changed for loop to re-use the same variable as iterator (maybe we should make sure that we reset the unit in case the user has changed it, since we only change the actual value ... can we even iterate over pixels?).

Made some benchmarks with a very big for loop:

@for $i from 1 through 20000000 {}
// from: 10 wallclock secs ( 9.30 usr +  0.67 sys =  9.97 CPU) and ~ 3GB RAM
// to  :  0 wallclock secs ( 0.05 usr +  0.00 sys =  0.05 CPU) and no ram inc

[akhleung]

Ooh, pretty cool! It'll be interesting to see the impact on large scss projects.

[am11]

👍
Perhaps this is related: I have observed some significant performance decrease when running the huge test with v3.2.0-beta.2 (compared to v3.1.0) via node-sass test runner.

[drewwells]

Seeing ~0.8% speedup on project compile time vs 3.2.0-beta.2

[mgreter]

@drewwells I'm actually quite surprised that you see such an improvement. My benchmark test was really not a real-wold case and I was more concerned with the memory usage there (DOS). I would also like to implement memory limits for allocations as it should be trivial inside memory manager.

[drewwells]

Yeah I thought 0.8% was really impressive. The performance graph does show
a lot of time is spent compiling and freeing the compiler context vs OS
tasks like file I/O.

On Thu, Mar 26, 2015 at 1:52 PM Marcel Greter [email protected]
wrote:

@drewwells https://github.com/drewwells I'm actually quite surprised
that you see such an improvement. My benchmark test was really not a
real-work case and I was more concerned with the memory usage there (DOS).
I would also like to implement memory limits for allocations as it should
be trivial inside memory manager.

—
Reply to this email directly or view it on GitHub
#985 (comment).

[mgreter]

Btw. related issue #613

[mgreter]

I actually have another optimization pending in https://github.com/mgreter/libsass/tree/refactor/prelexer. With that branch, my spec runner reports a pretty nice improvement 😄 So stay tuned!

in 14 wallclock secs (14.24 usr +  0.47 sys = 14.71 CPU)
in 12 wallclock secs (10.94 usr +  0.58 sys = 11.51 CPU)

[drewwells]

rock on 💯 !