Search Unity

Update() oddity

Discussion in 'Scripting' started by slipstream, May 4, 2008.

  1. slipstream

    slipstream

    Joined:
    May 4, 2008
    Posts:
    21
    Hi all,

    I have built a c# script which with the help of an external plugin retrieves texture data via network and updates texture of the object it is associated with.

    Now the odd thing is that while everything appears to work, when using larger textures, Unity quickly starts to lag in interpreting received packets and as a result there is a traffic jam of packets at the socket which is also confirmed by the sending client. At first I thought this was the problem of network packet sizes (in this case network connection is on localhost), then the code inefficiency, and when I thoroughly checked the code and tested various scenarios, I found out that none of these were the case. Rather, it appears that if I add a print command inside the Update() method, even on very large textures, then Unity updates as instructed (although with a considerable increase in CPU usage, likely mainly due to the aforesaid addition of heavy print output), but when the print commands are omitted, the texture playback slows down, starts lagging behind in reading packets, and yet the cpu usage remains quite low.

    The structure of the Update() function can be summarized as follows:

    Code (csharp):
    1. Update() {
    2.  
    3. texUpdated = false;
    4.  
    5. if (connection available) {
    6.   connect;
    7.   read-flag = true;
    8. }
    9.  
    10. while (netStream.dataAvailable  read-flag)
    11. {
    12.   if (!header-flag) {
    13.     try {
    14.       read packet header data;
    15.       set header-flag to true;
    16.     }
    17.     catch odd situations and reset;
    18.   if (header-flag) {
    19.     try {
    20.       read texture data;
    21.       PRINT(current_amount_of_data_read);
    22.       /*the aforesaid print command prints multiple times per update due to "while" statement and because larger textures cannot fit into a single network packet--this is also what makes the Update() behave as expected, rather than becoming sluggish while utilizing only a fraction of cpu*/
    23.       if (data read == texture dimensions) {
    24.          if (!texUpdated) {
    25.            invoke plugin that updates texture;
    26.            texUpdated = true;
    27.            /*this last step is to avoid doing multiple textures per update cycle, so the rest will be dropped due to aforesaid while clause*/
    28.          }
    29.          header-flag = false;
    30.          /*this flag enables reading of consequent packets until the while loop runs out of data available. However, on subsequent runs update texture plugin is not invoked as texUpdated is set to true until next time Update() function is run*/
    31.       }
    32.     }
    33.     catch odd situations and reset;
    34.   }
    35. }
    So, what seems to be the case is that somehow Update() calls become inefficient (perhaps in order to conserve cpu?) when there is no printout. Yet, when there is printout everything works as expected, although the CPU usage triples (likely because of excessive print commands). Not that this possible explanation makes any sense, but could this be because of the while command within Update() method? Or is this simply a bug?

    BTW, this is using Unity Pro 2.0.2f2.

    UPDATE:
    Earlier this afternoon I also tried separating texture update calls into a separate Coroutine (via StartCoroutine) as well as the other way around where networking code was in a separate coroutine while texture update was the only call within the Update() method. The interesting thing is when I don't have any print statements, the texture update flickers suggesting it is out of sync with the filling of the data buffer (even though I have a boolean statement that controls its iteration) and the slowdown/lag persists. But as soon as I add one print("") statement in the update cycle in the aforesaid spot (where the data buffer is concatenating network packets), everything seems to work just fine (except once again, I am printing into the console and likely using extra CPU as a result of it).