koobas.hobune.stream
Performance issue loading resource
Greetings,
I would like to hear some suggestion on how could I get over this situation:
I have a catalog that is presented in a scroll view. It´s components are stored in a text asset with over 9,000 lines (each line represents an indivudual entry with it´s features) and parsed into a list.
The problem is that the app takes too long to load and build the list. Usually it takes over 20 seconds to load (considering iPad... make it ~10 seconds on the macbook using unity editor). The main interface and user interaction will only take place when the loading process is complete. Our project would only be fine with 5 seconds to load.
Basically the text asset has it´s lines splitted into a string array and then each of the +- 9,000 lines get parsed again with Split(...) to extract the data for each component.
I tried to load 500 entries, start the app and later load bit by bit while still running the app, but it get´s the FPS to the ground (~3 to 8 FPS as opposed to 200+ FPS using the regular way).
I also tried to load 500 entries and then given specific triggers load a bit more, like when you scroll the scrollview too much it would load 40 more entries, but it´s lags too much (~1 second) and it doesn´t look good at all.
I did a method that checks if the touch device isn´t getting any touches for some time and then load all the entries it can while it´s idle touch-wise. But this does not solve the problem.
I thought on threads but I am not sure how C# threads would work on iPad.
Well, I hope someone could give me a suggestion on this situation!
Thanks!
Have you tried to split the reading function over several frames using yield? You could read the 400 first lines, then enter a loop where up to 40 lines were read and the yield instruction executed until the whole file were read - something like this pseudo code:
function Start(){
... // read the first 400 lines
while (not eof){ // pseudo code, obviously
... // read up to 40 (for instance) lines
yield; // suspend routine and return to this loop next frame
}
}
Yield places the function on hold and lets Unity to do other jobs until the next frame, when it returns to the instruction right after yield and resumes the execution.
The coroutine aproach didn´t solve the performance issue. Yet it made the problem less visible.
I moved to another aproach which consisted of not loading/parsing the catalog elements at the startup. Ins$$anonymous$$d of that, I loaded a simplified version of those elements only with the necessary information to render the buttons on the scroll view. Then, when a button gets clicked the "real" version is fully loaded and the lag is close to none.
The initial loading time dropped 66% of the original time (20 secs to 7 secs on iPad 1) with 9,316 elements parsed.
