Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
CODE PROJECT For Those Who Code
  • Home
  • Articles
  • FAQ
Community
  1. Home
  2. The Lounge
  3. I'm being too clever for my own good but I'm really not: analysis paralysis

I'm being too clever for my own good but I'm really not: analysis paralysis

Scheduled Pinned Locked Moved The Lounge
graphicsperformancealgorithmsdesigngame-dev
12 Posts 6 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • honey the codewitchH honey the codewitch

    For a long time, I've wanted my graphics library GFX to be able to use temporary RAM to cut down on bus traffic. How it works is, it takes a lot of traffic to even write a single pixel. There's very little overhead however, for writing a bitmap. So what I intend to do is back some of my drawing operations with bitmaps - at least where it's possible. It gets tricky though, because I'm constantly dealing with memory pressure. So what I do is I try to allocate a bitmap to hold the entire draw. If there's not enough memory, I keep dividing the height of the bitmap by half and trying until I'm down to a single line. If I still can't do it I go pixel by pixel. This works because the little heap - at least on the ESP32 - is blazing fast - maybe because it deals with so little RAM? I feel good about this because to the degree that I've got it working it really speeds things up, but gosh is it going to be hard to maintain and it's really hard to code. Putting on my design hat, I'm torn. This is a graphics library so some allowances must be made for performance reasons in terms of writing maintainable code. On the other hand, holy elephant this is difficult, and that makes alarm bells ring. I learned most of the development skills that serve me in the IoT realm when I was a kid banging out code on 8-bit and 16-bit systems. However, not having the professional experience I didn't care about readability or maintenance. Years of professional development have on one hand given me an advantage in that department, but it sort of paralyzes me in situations like this where the pull from my professional experience is STOP BEING CLEVER and yet any significant optimization I do pays for itself down the line because of the nature of the library. Graphics need to be as fast as they can reasonably be. I mean, I'm not banging out hand optimized ASM and I never would for IoT - too many different processors to target even on the ESP32 line - but algorithm level improvements are always fair game. I eventually work through it but the point is my experience is actually slowing me down here. In some ways working on massive servers and desktops with gobs of RAM has spoiled me - and I'm quickly learning that sometimes readable code is a luxury. Edit: I made it go, figured out a way to cut maintenance to 1/3rd and then decided to blow it up again by making it capable of doing all this asynchronously by alternately writing to one bitmap while sending the other in the background, and then flipping the pointers and alternating

    Greg UtasG Offline
    Greg UtasG Offline
    Greg Utas
    wrote on last edited by
    #2

    Transcriptions of your conversations with your rubber duck are often interesting. :)

    Robust Services Core | Software Techniques for Lemmings | Articles
    The fox knows many things, but the hedgehog knows one big thing.

    <p><a href="https://github.com/GregUtas/robust-services-core/blob/master/README.md">Robust Services Core</a>
    <em>The fox knows many things, but the hedgehog knows one big thing.</em></p>

    1 Reply Last reply
    0
    • honey the codewitchH honey the codewitch

      For a long time, I've wanted my graphics library GFX to be able to use temporary RAM to cut down on bus traffic. How it works is, it takes a lot of traffic to even write a single pixel. There's very little overhead however, for writing a bitmap. So what I intend to do is back some of my drawing operations with bitmaps - at least where it's possible. It gets tricky though, because I'm constantly dealing with memory pressure. So what I do is I try to allocate a bitmap to hold the entire draw. If there's not enough memory, I keep dividing the height of the bitmap by half and trying until I'm down to a single line. If I still can't do it I go pixel by pixel. This works because the little heap - at least on the ESP32 - is blazing fast - maybe because it deals with so little RAM? I feel good about this because to the degree that I've got it working it really speeds things up, but gosh is it going to be hard to maintain and it's really hard to code. Putting on my design hat, I'm torn. This is a graphics library so some allowances must be made for performance reasons in terms of writing maintainable code. On the other hand, holy elephant this is difficult, and that makes alarm bells ring. I learned most of the development skills that serve me in the IoT realm when I was a kid banging out code on 8-bit and 16-bit systems. However, not having the professional experience I didn't care about readability or maintenance. Years of professional development have on one hand given me an advantage in that department, but it sort of paralyzes me in situations like this where the pull from my professional experience is STOP BEING CLEVER and yet any significant optimization I do pays for itself down the line because of the nature of the library. Graphics need to be as fast as they can reasonably be. I mean, I'm not banging out hand optimized ASM and I never would for IoT - too many different processors to target even on the ESP32 line - but algorithm level improvements are always fair game. I eventually work through it but the point is my experience is actually slowing me down here. In some ways working on massive servers and desktops with gobs of RAM has spoiled me - and I'm quickly learning that sometimes readable code is a luxury. Edit: I made it go, figured out a way to cut maintenance to 1/3rd and then decided to blow it up again by making it capable of doing all this asynchronously by alternately writing to one bitmap while sending the other in the background, and then flipping the pointers and alternating

      0 Offline
      0 Offline
      0x01AA
      wrote on last edited by
      #3

      Sorry for that, I could not resist ;) Right Said Fred - I`m Too Sexy The (Original) (Audio) - YouTube[^]

      honey the codewitchH 1 Reply Last reply
      0
      • 0 0x01AA

        Sorry for that, I could not resist ;) Right Said Fred - I`m Too Sexy The (Original) (Audio) - YouTube[^]

        honey the codewitchH Offline
        honey the codewitchH Offline
        honey the codewitch
        wrote on last edited by
        #4

        I'm too clever for my app, too clever for my app what do you think about that? You know I'm a coder, and you know what that means? I write C++ on my laptop yeah on my laptop, yeah on my laptop I write C++ on my laptop

        To err is human. Fortune favors the monsters.

        R J 2 Replies Last reply
        0
        • honey the codewitchH honey the codewitch

          I'm too clever for my app, too clever for my app what do you think about that? You know I'm a coder, and you know what that means? I write C++ on my laptop yeah on my laptop, yeah on my laptop I write C++ on my laptop

          To err is human. Fortune favors the monsters.

          R Offline
          R Offline
          RedDk
          wrote on last edited by
          #5

          Great. Since you're doing nothing, I've got some kernals of corn in my cornbread mix which I'd like you ta pick out. I'm averse to baking cornbread in the first place. Especially without eggs or milk. The recipe says quite clearly "milk" and "egg". Right there on the side of the mix box. Of all places. Really. Crunchy cornbread. Who are these people? :flako:

          1 Reply Last reply
          0
          • honey the codewitchH honey the codewitch

            I'm too clever for my app, too clever for my app what do you think about that? You know I'm a coder, and you know what that means? I write C++ on my laptop yeah on my laptop, yeah on my laptop I write C++ on my laptop

            To err is human. Fortune favors the monsters.

            J Offline
            J Offline
            jmaida
            wrote on last edited by
            #6

            For me that would like programming through a knot hole. But that's me. I want big screens, husky keyboards and really fast computation. I can't say that I understand what you are working with (compiler/header/macros/etc.) but when I start to get overdone with code, I do the divide and conquer approach. Just saying.

            A little time, a little trouble, your better day. (BF)

            honey the codewitchH 1 Reply Last reply
            0
            • J jmaida

              For me that would like programming through a knot hole. But that's me. I want big screens, husky keyboards and really fast computation. I can't say that I understand what you are working with (compiler/header/macros/etc.) but when I start to get overdone with code, I do the divide and conquer approach. Just saying.

              A little time, a little trouble, your better day. (BF)

              honey the codewitchH Offline
              honey the codewitchH Offline
              honey the codewitch
              wrote on last edited by
              #7

              i solve it. i didn't need to break it down because I already had a solid idea of how it had to work at a high level. The parts that were difficult were all the details. I knew what had to be there, but getting it right without a debugger was the challenge. I got lucky though - for the most part it was smoother than I expected.

              To err is human. Fortune favors the monsters.

              J 1 Reply Last reply
              0
              • honey the codewitchH honey the codewitch

                i solve it. i didn't need to break it down because I already had a solid idea of how it had to work at a high level. The parts that were difficult were all the details. I knew what had to be there, but getting it right without a debugger was the challenge. I got lucky though - for the most part it was smoother than I expected.

                To err is human. Fortune favors the monsters.

                J Offline
                J Offline
                jmaida
                wrote on last edited by
                #8

                Excellent. You can sleep better tonight. BTW your laptop model is by far more energy efficient.

                A little time, a little trouble, your better day. (BF)

                1 Reply Last reply
                0
                • honey the codewitchH honey the codewitch

                  For a long time, I've wanted my graphics library GFX to be able to use temporary RAM to cut down on bus traffic. How it works is, it takes a lot of traffic to even write a single pixel. There's very little overhead however, for writing a bitmap. So what I intend to do is back some of my drawing operations with bitmaps - at least where it's possible. It gets tricky though, because I'm constantly dealing with memory pressure. So what I do is I try to allocate a bitmap to hold the entire draw. If there's not enough memory, I keep dividing the height of the bitmap by half and trying until I'm down to a single line. If I still can't do it I go pixel by pixel. This works because the little heap - at least on the ESP32 - is blazing fast - maybe because it deals with so little RAM? I feel good about this because to the degree that I've got it working it really speeds things up, but gosh is it going to be hard to maintain and it's really hard to code. Putting on my design hat, I'm torn. This is a graphics library so some allowances must be made for performance reasons in terms of writing maintainable code. On the other hand, holy elephant this is difficult, and that makes alarm bells ring. I learned most of the development skills that serve me in the IoT realm when I was a kid banging out code on 8-bit and 16-bit systems. However, not having the professional experience I didn't care about readability or maintenance. Years of professional development have on one hand given me an advantage in that department, but it sort of paralyzes me in situations like this where the pull from my professional experience is STOP BEING CLEVER and yet any significant optimization I do pays for itself down the line because of the nature of the library. Graphics need to be as fast as they can reasonably be. I mean, I'm not banging out hand optimized ASM and I never would for IoT - too many different processors to target even on the ESP32 line - but algorithm level improvements are always fair game. I eventually work through it but the point is my experience is actually slowing me down here. In some ways working on massive servers and desktops with gobs of RAM has spoiled me - and I'm quickly learning that sometimes readable code is a luxury. Edit: I made it go, figured out a way to cut maintenance to 1/3rd and then decided to blow it up again by making it capable of doing all this asynchronously by alternately writing to one bitmap while sending the other in the background, and then flipping the pointers and alternating

                  J Offline
                  J Offline
                  jochance
                  wrote on last edited by
                  #9

                  Quote:

                  This is a graphics library so some allowances must be made for performance reasons in terms of writing maintainable code.

                  I think this is right, personally. But I'd even extend it further. You can always circle back and improve that and someone who can't read it, they can re-write it for legibility if they think it's that bad. Not all cleverness or brevity actually results in more performance. Being clever/concise at the expense of legibility with total disregard to performance is probably wrong. Sacrificing performance for legibility? Likewise, we should probably almost never be doing that. Sounds like you did awesome... and on hard stuff.

                  honey the codewitchH 1 Reply Last reply
                  0
                  • J jochance

                    Quote:

                    This is a graphics library so some allowances must be made for performance reasons in terms of writing maintainable code.

                    I think this is right, personally. But I'd even extend it further. You can always circle back and improve that and someone who can't read it, they can re-write it for legibility if they think it's that bad. Not all cleverness or brevity actually results in more performance. Being clever/concise at the expense of legibility with total disregard to performance is probably wrong. Sacrificing performance for legibility? Likewise, we should probably almost never be doing that. Sounds like you did awesome... and on hard stuff.

                    honey the codewitchH Offline
                    honey the codewitchH Offline
                    honey the codewitch
                    wrote on last edited by
                    #10

                    jochance wrote:

                    Sacrificing performance for legibility? Likewise, we should probably almost never be doing that.

                    I'm going to be difficult here, and say there's a time and a place for that too. I've been an architect for million dollar implementations involving teams of people, sometimes not even working in the same country. You get hit with diminishing returns really quickly the larger and more "spread out" your project is in terms of throwing brainpower at your problem vs. throwing more hardware at it, *especially* in this venue where legibility and consistency/uniformity of operation is paramount due to the number of eyes and hands on the code. That was my life for awhile, and I didn't really enjoy it. There were other aspects of that career trajectory that were worse though, but that's all aside from my point. Still, software efficiency isn't always a priority. A lot of times it doesn't even rank in business development. Maybe it should? but it doesn't.

                    To err is human. Fortune favors the monsters.

                    J J 2 Replies Last reply
                    0
                    • honey the codewitchH honey the codewitch

                      jochance wrote:

                      Sacrificing performance for legibility? Likewise, we should probably almost never be doing that.

                      I'm going to be difficult here, and say there's a time and a place for that too. I've been an architect for million dollar implementations involving teams of people, sometimes not even working in the same country. You get hit with diminishing returns really quickly the larger and more "spread out" your project is in terms of throwing brainpower at your problem vs. throwing more hardware at it, *especially* in this venue where legibility and consistency/uniformity of operation is paramount due to the number of eyes and hands on the code. That was my life for awhile, and I didn't really enjoy it. There were other aspects of that career trajectory that were worse though, but that's all aside from my point. Still, software efficiency isn't always a priority. A lot of times it doesn't even rank in business development. Maybe it should? but it doesn't.

                      To err is human. Fortune favors the monsters.

                      J Offline
                      J Offline
                      jochance
                      wrote on last edited by
                      #11

                      Nah, not so difficult. Totally reasonable. I was careful to couch it with "probably almost". You can probably easily rewrite the legible into the performant anyway... every time if need be. Afterall, it's legible, and you do have unit tests, so make them work for you. One of the only things I might wax purist on are the detrimental effects of purist mindsets. I think relative infancy is why many things just don't "rank in business development". People can't even fill their dev chairs with devs, forget filling all the management chairs with managers who can dev. I think you go two steps up many management chains and you arrive at a spot where the nuts and bolts are all but Greek. Some would be speaking Greek even one step up. It isn't that they can't grok Greek. But if you want to talk bit shifts or something, you're going to need to do some explaining. Seeing gfx and clever I couldn't help but be reminded of: i = 0x5f3759df - ( i >> 1 );

                      1 Reply Last reply
                      0
                      • honey the codewitchH honey the codewitch

                        jochance wrote:

                        Sacrificing performance for legibility? Likewise, we should probably almost never be doing that.

                        I'm going to be difficult here, and say there's a time and a place for that too. I've been an architect for million dollar implementations involving teams of people, sometimes not even working in the same country. You get hit with diminishing returns really quickly the larger and more "spread out" your project is in terms of throwing brainpower at your problem vs. throwing more hardware at it, *especially* in this venue where legibility and consistency/uniformity of operation is paramount due to the number of eyes and hands on the code. That was my life for awhile, and I didn't really enjoy it. There were other aspects of that career trajectory that were worse though, but that's all aside from my point. Still, software efficiency isn't always a priority. A lot of times it doesn't even rank in business development. Maybe it should? but it doesn't.

                        To err is human. Fortune favors the monsters.

                        J Offline
                        J Offline
                        jmaida
                        wrote on last edited by
                        #12

                        Well said!

                        1 Reply Last reply
                        0
                        Reply
                        • Reply as topic
                        Log in to reply
                        • Oldest to Newest
                        • Newest to Oldest
                        • Most Votes


                        • Login

                        • Don't have an account? Register

                        • Login or register to search.
                        • First post
                          Last post
                        0
                        • Categories
                        • Recent
                        • Tags
                        • Popular
                        • World
                        • Users
                        • Groups