But then it would create a different plan - the point (or assumption) was that the plans were the *SAME* and yet statement cache was somehow 2x slower.
WRT to the query itself - this is pretty much a classic query tuning problem - will reply privately. But all suspicions point to drastically different plans due to a couple of common issues:
1) 2+ partial index choices available - SARGs not well covered by any single index
2) Query contains unbounded date range - this is typically a problem due to the fact that business case typically has an implicit bound that isn't reflected in the query - but within ASE we have an unbounded date range - in which most cases, the single column density is >40% of the table and consequently the date predicate is unusable for index selection.
This leaves us often with #1 and quite often ASE simply picking the smaller index and doing a range scan of the leaf nodes plus data page lookup for each qualifying leaf value.
But, btw - anything in proc cache gets sproc timeout - so issuing the query via fully prepared statement would have the same effect as statement cache. The point being here is that the extra optimization time allows ASE to do more optimization strategies and given (1) & (2) it likely picks the wrong plan out of the extra time due to perception that a plan has a lower overall cost than the index range scan. Usually, this will show up as a change in the join order or join method (e.g. MJ vs. NLJ).