Have you tried running 'update index stats' against all of your system tables (in the database you're running ddlgen against)?
ddlgen has to run queries against the system tables to do it's thing, so tracking down a performance issue with ddlgen would include analyzing its queries against the system tables.
1 - In databases with as few as 1000 objects I've seen performance problems with assorted system stored procs (which have to query system tables); in those situations I found that updating stats on the system tables provided a performance boost for the system procs.
NOTE: I recommend running 'update index stats' against all (non-fake, non-syslogs) system tables at the same time you're updating stats on user tables. System tables are relatively small so the operation takes little time and while it may be overkill for most environments the benefits can be quite noticeable in databases with largish system tables.
2 - Are you seeing prformance problems with other non-system-table queries in your dataserver? If so I'd also want to take a look at your cache configuration(s).
NOTE: System tables have to reside somewhere in cache, which by default is the 'default data cache'. If you're trashing your caches (eg, flushing system tables from memory/cache) then any follow-on queries against said system tables (eg. ddlgen queries) will be delayed while waiting to pull the system tables back into cache. You could also see a performance degradation in the query compilation phase (heavily dependent on system tables) if the system tables have to be pulled from disk. In the past I've setup some clients with a separate cache specifically for system tables for the sole purpose of insuring the system tables remain in cache (Jeff Tallman touched on this same topic a couple days ago in this forum - see his post about ASE 16 + VLDB + VLH).
3 - I would also expect ddlgen submits a lot of queries of the same format but different SARGs soooo, I'd probably want to verify that statement cache is enabled, too.
