Is it problematic that the Start method ( in a class inheriting the MonoBehavior ) takes too long time ?

Suppose a scene includes an object and a script is attached to that object.

Then if the overridden Start method ( in the class inheriting the MonoBehavior) takes too long time(
but definitely finishes in finite steps and the memory is sufficient ),

that scene will be at risk of freezing or stopping ?

In other words, is there a time-limit such that the Start method takings time more than

the time-limit is stopped though the Start method itself definitely finishes in finite steps and
the memory is sufficient?

Or the initialization by the Start method only takes too long time and gives bad user experience ?

Hello.

As far as I know, it will not cause any problem once is completed. I mean, diring the first seconds, will process all the Starts, and yes, will seem freeze. But once Completed with all Starts, it should go fine.

Well the problem has several seperate aspects to it. First of all you said it’s guaranteed to terminate in finite steps. This however is not a guarantee that it terminates within the life-time of the universe (see Ackermann’s function for example). So it’s more of a matter does it finish in “reasonable” time.

There are several factors that might come into play here. First it might take “too long” for a user to wait for (bad user experience). What is too long is not a hard limit as it depends on the user. However depending on the platform there might be artificial hardlimits that might cause you trouble. For example on Windows if an application main GUI thread does not react to input messages within a certain time frame, Windows will notify the user that the application is “not responding”. This might alarm certain users that there’s something wrong. A similar mechanic exists on most operating systems mainly to protect the user from hanging apps and it usually offers the option to terminate the application.

This is some inconvenience for the user and your application. However there are other platforms which might have setup certain quality standards which have to be reached in order to get the application accepted. The most critical platform I know of is iOS / apple. I don’t know the exact numbers but the startup of an app must not be longer than a certain period. AFAIK this even includes startup that actually has feedback (a loading bar). Though the no-feedback period is way shorter.

So technically there are no issues at all. If you want to calculate a 2^3000 zoom into the mandelbrot set at startup of you app you can do that, but it might take a couple of month until it’s done. The problems you can encounter are mostly from the users or restrictions of a publishing platform.

Just to be explicit here: Unity doesn’t care what you do, at all. There are no watchdog timers that somehow interrupt your code. When Unity invokes a callback of yours all the control of the application is in your hands. Unity won’t do anything (relevant) until you return the control back to Unity by finishing the callback.