Announcement

Collapse
No announcement yet.

pbp 3.1.0 - time taken to compile

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • pbp 3.1.0 - time taken to compile

    HI charles , i recently downloaded 3.1.0 and are finding it taking alot longer for known code to be compiled,

    I have a large code that compiles to 126k , it previously took about 30secs on earlier version 3.0.8 , now i am finding the same code takes 2mins on the same machine

    any insight why this may be the case

  • #2
    I've noticed this, too. For many years, the PBP executable was developed and compiled in Microsoft Visual Studio 6 on a Windows XP system. For PBP 3.0.10 and later, we were forced to migrate to a current system using Visual Studio 2015. This not only broke compatibility for WinXP systems, but it also seems to have slowed the compiler significantly.

    I have no solution, except to upgrade to a faster computer. (A solid-state drive helps.) I'm sure Microsoft defines this as "progress".

    For readers that might be alarmed by this, I would point out that PBP still takes only a few seconds to compile most programs. When we talk about a program that fills 128K of code space, that equates to a very long program. In my case it's more than 10000 lines of BASIC code.

    Related clue for all versions of PBP: If you open and compile your program from a network drive or a USB drive, PBP slows down A LOT. It's always a good idea to save you program to a local drive with fast access when compiling.
    Charles Leo
    ME Labs, Inc.
    http://melabs.com

    Comment


    • #3
      ok , new machine be nice ,

      the compile window will often freeze when doing a large file compile , - with "no response " in the code window , then some 2 mins later the build window will show up and take a further 30sec , i have not ported the code yet into Mlapx for comparison compile times

      Comment


      • #4
        Charles, I also notice a bit of a delay when compiling my solar tracker program for a 18F67K22 using longs. It also indicates NO RESOPNCE when launched into compile state. About a minute later I see the ASM screen. The program compiles to about 76161 bytes.
        Dave Purola,
        N8NTA
        EN82fn

        Comment


        • #5
          David, are you personally soldering the PIC18F67K22 to the board or do you have some assembly house do it for you? I've been trying to use one but always have at least one (or more) pin that just isn't right. I'm soldering it myself. Just curious.

          Comment


          • #6
            No, I do not use a board house. I do everything myself. One man show....
            Dave Purola,
            N8NTA
            EN82fn

            Comment


            • #7
              There is no progress indicator during compilation. This is what I observe on my Windows 7 Pro system (i7-4790 @ 3.60GHz, solid state drive, PIC18F87K22, 130951 bytes used):

              The compile process takes about 50 seconds. The only indicator is a spinning mouse cursor. (Windows randomly adds the text "not responding" to the title bar of MCSX. This doesn't happen every time.)

              The MPASM dialog pops up and assembly takes about 17 seconds.


              My Windows Experience Indexes are as follows:
              Processor 7.8
              Memory (RAM) 7.8
              Graphics 5.8
              Gaming graphics 6.9
              Primary hard disk 7.5

              If your systems are slower than mine, I think your compile times are normal. I will press the exe developer again to see if he can speed things up, but I'm not optimistic. As I said before, I think Microsoft and our modern world define this as progress. Development systems 20 years ago were much more efficient because they had to be. Modern systems presume that we all have super-computers and gigabit-internet, and that what we want more than anything is constant access to social media.

              I could rant. I really could.
              Charles Leo
              ME Labs, Inc.
              http://melabs.com

              Comment


              • #8
                Hi charles , i am also compiling for 18f87k22 , , the project requires 5 compiles per testing a pcb code , 4 compiles to preload / create all the data for the flash memory installs( 96k, 115k, 122k, 78k, each , then 1 more for the final operating program install of 126k,

                the system is win10 64bit amd A6-3670 @2.90g, with 16g mem ,

                all do what your does in no responce in the window , times vary for each compile , but the time do do a compile has blown out to about 6mins for the total project compile , where , before it was under 2


                i am fighting hard to keep the final code to fit into a 128k chip , a f24 would be nice , just to have some more space for the code , but thats not coming soon to picbasic i guess

                Comment


                • #9
                  Ouch. That sounds painful.

                  In that situation, I think I would move back to PBP 3.0.9, at least for the bulk of development. There is a slight concern related to LONG array variables, but you can safeguard against the issue by specifying the addresses of the arrays. http://support.melabs.com/articles/p...ay-have-issues
                  Charles Leo
                  ME Labs, Inc.
                  http://melabs.com

                  Comment


                  • #10
                    Yes its not ideal and very noticable, but when production I just copy flash prom sectors and transfer directly to other flash chips , then only need to load the op code so not such a pain

                    Amy chance on commenting on the f24 devolopment you spoke about a year back as a possibility

                    Comment


                    • #11
                      I haven't had any success selling the PIC24 development project. None of our estimates show any chance of profiting from it. The money just isn't there.
                      Charles Leo
                      ME Labs, Inc.
                      http://melabs.com

                      Comment


                      • #12
                        thats sad , as any code exceeding 128k chips is a problem , unless pehaps microchip make 18f chips with more than 128k , then perhaps some support for them may happen ?

                        Comment


                        • #13
                          Yes, if Microchip makes a PIC18 with more code space, it shouldn't be a problem - depending on how much they change the workings of the part. PBP already supports extended code space with external memory on the devices that are capable of microprocessor-mode, but this is of limited use because it's painful to get the code into memory.
                          Charles Leo
                          ME Labs, Inc.
                          http://melabs.com

                          Comment

                          Working...
                          X