Since I do no know much details about your system from your Question I try to to explain the main reasons for long startup times.
1. Your number of submitted entities to load reached a point where the java virtual machine starts to do a lot of garbage collection slowing down performance drastically.
You can check this by running a 'SHOW SYSTEM' using sdmsh and check whether available memory is low. Reconfiguring the java heap size in $BICSUITECONFIG/java.conf to allow for more heap can help.
2. The loading of the repository is slow because too much history has to be loaded.
You can check the the history settings in $BICSUITECONFIG/server.conf to reduce the number of history days to load.
which can have a number of reasons.
3. Your system is running for quite a long time and the database tables have grown very big.
In this case you should configure the dbhistory settings in $BICSUITECONFIG/server.conf to have the server automatically clean up the database from outdated runtime information.
Optionally the removed data can be saved in archive tables to keep information for analysis and compliance reasons, which also can configured in server.conf.
After restarting the server it will then start to cleanup outdated runtime information from the schedulix live tables.
Keep in mind that depending on the database system you use, you may have to run some reorganization utility/command on large tables with lot of deleted space to reclaim unused space and pack the valid data for fast retrieval, after the scheduling server has finished to remove old data from the live tables. This reorganization/optimization of the database tables has to be done while the schedulix server is down.
Of course the schedulix server has to be restarted after changing any config files in $BICSUITECONFIG for changed to take effect.
Hope this helps you out.
Regards
Dieter