Solidity: Take a look at comedy

[chriseth]

https://github.com/figs999/Ethereum/blob/master/Solc.aComedyInOneAct

[veox]

@figs999 - did you enable the optimiser for that program?..

---

EDIT: Chris' notes on /r/ethdev. ("Need info".)

[chriseth]

Oh yeah, now I see where this is coming. The code generated for x.push(y) is basically equivalent to the code generated for x.length++; x[x.length-1] = y;, although it could be much more specific. The problem is the x.length++ - this is just an arbitrary assignment to the length property, which can of course lead to way more different outcomes.

[chriseth]

3690 should fix the problems with incrementing the size of the storage array, but the optimizer actually used to be able to combine multiple sstore operations to the same slot into a single one. We should investigate why this is no longer the case.

[chriseth]

Hm, 0.4.11 is still able to combine the sstore operations.

[chriseth]

I fear the "mark MLOAD to have side-effects in the optimizer" is the culprit. Why did it take half a year for someone to notice? Unfortunately, we did not have high-level performance tests for the optimizer, just low-level ones...

[veox]

Why did it take half a year for someone to notice?

TBH, I did feel that "contracts have been getting more sluggish recently", but kept discarding that thought as "one of a grumpy old fart's".

[figs999]

Hey Guys, glad you enjoyed my script. I actually did not anticipate that it contained anything that was actually an issue, and had assumed the unusual behaviors I poked fun at were being done because they were part of intentionally re-used op routines.

To answer your question about the optimizer, no, I don't believe so. But I recall running it with and without optimizer and that the operations were not substantially different in the routine for composing and storing a struct.

A few of the amusing parts around managing array length were removed/obscured by the optimizer, which is why I went for the non-optimizer version for my skit.

[chriseth]

@figs999 good that you didn't reply right away and I actually tried running the optimizer against it :)

Now saving the struct should again be just a single SSTORE. Unfortunately, we cannot remove the intermediate memory stores. The optimizer operates at a lower level and cannot detect whether memory will be used later or not, but I hope that a future optimizer might be able to do that.

[figs999]

Now saving the struct should again be just a single SSTORE. Unfortunately, we cannot remove the intermediate memory stores. The optimizer operates at a lower level and cannot detect whether memory will be used later or not, but I hope that a future optimizer might be able to do that.

What about adding a new restricted struct type, similar to the stack-only method I used in my "virtual struct" example?

I imagine that that would reduce the overhead when dealing with <=32byte structures. Unless of course you believe the gas differential I found is the result of the issues that you are already working on, and not the memory usage.

[chriseth]

I don't think we should complicate the type system. People are already confused by storage and memory. Furthermore, for larger structs, they will complain that they cannot use more than 10 variables....

No, this is the optimizer's job.

[chriseth]

Fixed by #3693 and #3690 .