Search Unity

Feedback Having the amount of compiling code in realtime.

Discussion in 'Scripting' started by AlanMattano, Jun 1, 2021.

  1. AlanMattano

    AlanMattano

    Joined:
    Aug 22, 2013
    Posts:
    1,501
    This just utopia right now but an idea for the future.
    When we are making a script can be nice to look in realtime the amount of compiling code. An integer number is displayed that shows the value of the amount of compiled code. So if we are making an optimization probably the value will go down as well.

    Just for that script. Probably needs VS integration. It can be done after saving. Also running just that script and display the number of milliseconds that takes to run it can be helpful.

    Jump to 4:00

     
  2. PraetorBlue

    PraetorBlue

    Joined:
    Dec 13, 2012
    Posts:
    7,909
    It's a nice idea but the number of lines of compiled code that are generated is not necessarily an indicator of code efficiency or performance. As Bjarne mentions in the video, a lot of performance comes down to memory locality and other things that are not nicely represented by a single metric such as "lines of code in the compiled output".

    I think ultimately what you're getting at though is some kind of "live profiling" of the code that you are currently writing. It's a nice idea but I can't imagine how it would be possible to do that in any kind of generic and scalable way :confused: . How would the IDE or compiler have any idea what kind of data should be fed into the code to test/profile it?
     
  3. Jonathan Blow has his new compiler. He is using it for writing his new game. He demonstrated on his live streams that it is capable of compiling and building 100k+ source under ~3 seconds including the external linkers (which are the majority of the time) and counting the lines in the mean time. The compiler is running less than a second for more than 100k code. Under a standard Unity roundtrip (haha) time I'm pretty sure there can be any kind of profiling happening in the background with that. Like Burstability, number of redirection in the code (virtual table sizes) and whatnot.
     
  4. PraetorBlue

    PraetorBlue

    Joined:
    Dec 13, 2012
    Posts:
    7,909
    In my mind it's not really a performance problem so much as a "generating reasonable and meaningful inputs to profile with" problem and a "halting problem" problem. I'm referring to a live profiling thing - not just counting lines of compiled code (which I think would be counterproductive).
     
  5. nsxdavid

    nsxdavid

    Joined:
    Apr 6, 2009
    Posts:
    476
    I find Jonathan Blow's new language such an oddity, in that he is creating this thing for super-optimal performance to enable a game he is working on... that needs no super-optimal performance. It's a little 3D puzzler, last time I looked that could be knocked out in Unity in a day without giving any significant or exceptional consideration to performance.

    Maybe he should up the ambition on the game he's trying to make to justify all the effort.
     
    Kurt-Dekker likes this.
  6. You're mistaken. It is not the reason. The game is just a testing ground. He's doing it as an experiment and to show how lazy our industry became (IT in general).
     
    bobisgod234 likes this.
  7. nsxdavid

    nsxdavid

    Joined:
    Apr 6, 2009
    Posts:
    476
    I don’t get the connection to laziness. (shrug)

    i like new domain-specific languages and have kicked out a fee in my time, still in production use. So I get that part.

    But when he demonstrates cool things like how arrays of structured data can be organized by the compiler for maximal CPU cache coherency with a game that benefits not at all from it.... I kinda start to wonder what he’s thinking.