Extremely inefficient Quartus Standard elaboration of VHDL function call tree conditional branches

Elaboration in Quartus Standard Edition is extremely inefficient in its processing of VHDL function call trees, taking an extremely long time with VHDL function call trees that have many conditional branches.

Experimenting with VHDL function call trees and measuring elaboration run times strongly suggests that Quartus Standard Edition elaboration evaluates *every* conditional branch through every level of the call tree, rather than just following the active conditional branch through every level.

Note that this pertains only to Quartus Standard Edition. Quartus Pro Edition doesn't exhibit this characteristic.

I'm providing a simple example that exhibits this behavior. It's a VHDL module (attached) that just sets a constant using a calling tree several functions deep (D), and where each function has several conditional branches (C) via a case statement that each call the next function below.

So if elaboration follows only the active conditional branch at every level, what would be the efficient thing to do, it takes a computational effort proportional to D. Whereas following every conditional branch, not just the active one, takes a computational effort proportional to C^D + C^(D-1) + C^(D-2) + ... + C, i.e. massive exponential growth.

Empirical run time measurements as a function of C and D suggest that Quartus Standard Edition does the latter, whereas Quartus Pro Edition does the former (as do Vivado, ISE, Modelsim, GHDL, and every other tool I have access to that performs elaboration on VHDL).

To run the example provided, place files example.vhd and example.tcl in a directory. In that directory, execute:

quartus_sh -t example.tcl

This issue is not merely academic. I currently have a real world design that takes several days to elaborate in Quartus Standard Edition because of this issue, whereas it takes less than a minute to elaborate in Quartus Pro and every other tool I've tried. So with extremely long run times in Quartus Standard Edition as a result of this inefficiency, targeting legacy Altera devices that aren't supported by Quartus Pro Edition becomes impractical. Which is a shame, because otherwise they would still be perfectly viable, and are still a large market on many existing hardware platforms.

I'd really like to see this fixed in Quartus Standard Edition if the device families not supported by Pro are to remain viable.