This is still a huge problem for some more complicated hyperelasticity problems. I profiled FFc and found that most of the ffc time was spent in split_expression doing:
prods.pop(0)
prods is a list, which is a stack and you do not do a pop(0) on a stack...
So the data structure was changed to a deque and that bottle neck disappeared.
However, Harish is using some even more evil forms than Anders (Johansen) is using, generating an .h file which is 48M big. With two lines basically filling the whole file. One within tabulate tensor which is 40M characters long(!?) and the signature line which is _only_ 3.4M characters long. It has been compiling now for 1.5h, still not finished.
There has to be optimizations, like grouped finiteelement method to reduce the complexity of the tabulate tensor function. Because essentially it boils down to the expansion of coefficient operations, right?
This is still a huge problem for some more complicated hyperelasticity problems. I profiled FFc and found that most of the ffc time was spent in split_expression doing:
prods.pop(0)
prods is a list, which is a stack and you do not do a pop(0) on a stack...
So the data structure was changed to a deque and that bottle neck disappeared.
However, Harish is using some even more evil forms than Anders (Johansen) is using, generating an .h file which is 48M big. With two lines basically filling the whole file. One within tabulate tensor which is 40M characters long(!?) and the signature line which is _only_ 3.4M characters long. It has been compiling now for 1.5h, still not finished.
There has to be optimizations, like grouped finiteelement method to reduce the complexity of the tabulate tensor function. Because essentially it boils down to the expansion of coefficient operations, right?