Announcement

Collapse
No announcement yet.

EFS Causing eSignal To Freeze

Collapse
X
Collapse
 
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts
Previous template Next
  • #1

    EFS Causing eSignal To Freeze

    I have run into an issue with an EFS I recently created.

    The problem is that the EFS is causing my computer and/or eSignal to freeze. Initially, the EFS was causing my computers CPU to run at 100% and ultimately pin there until a restart (during busy times of course). I recently upgraded to a very powerful computer (Quat Core Extreme 3.0...2GB of RAM) and the result is slightly different. The processor(s) never go above about, say, 25%, but eSignal now just freezes as things begin to get busy. I also need to restart. Even after eSignal freezes, the processor(s) are not running that hard. Presently, my new computer only has 1 screen as I run my tests on the EFS.

    The EFS I have created is complex so I know that is the first issue. A little background on the EFS:
    - It pulls up 5 other EFS’s using efsExternal().
    - 4 of the EFS’s it pulls were created by me, the other is MESA.
    - It has code for both back testing and automated trading within the EFS.
    - It uses getHour(0) and = getMinute(0). I know this is processor intensive.

    I have searched the forums in detail. I have found quite a bit about the processor being pinned at 100%, but this do not appear to be my problem on my new computer. I am confident that the problem is my EFS is simply inefficient (I.e. calling getMinute()…). I suspect, if I knew how to repackage things a bit more efficiently, it would solve my problem.

    What I could use help with is if anyone could look at the code and suggest how I can move things around to create efficiency.

    I have attached the EFS (MESA_Reversal v5.1.1) to this post.

    Regards,
    zMendel
    Attached Files
    Tags: None
  • #2
    Hi zMendel,

    I attached a modified efs that should be significantly more efficient. I don't have the external studies or Mesa so I couldn't test run the efs for testing purposes.

    I commented the changes I made, hope they make sense. Let me know if it works for you. If it doesn't, there may be some typos or other straightforward issues that can be fixed easily.

    Hope this helps.
    Attached Files

    Comment

    • #3
      EFS Causing eSignal To Freeze

      Steve:

      First, thanks so much for your help.

      Initially, it looks like there is a substantial savings on processor speed. When I put the old EFS and your updated EFS on one chart, your new EFS runs in about 1/3 the time.

      One question, I don’t see any of the drawShapeRelative results on the chart. Did you remove those in some fashion as you mentioned they are processor intensive.

      I am attaching all of the underlying EFS’s for your reference.

      Regards,
      zMendel

      Comment

      • #4
        CMI_Ergotic_Oscillator_v3.1.1.efs

        CMI_Ergotic_Oscillator_v3.1.1.efs
        Attached Files

        Comment

        • #5
          DTI_v3.1.1.efs

          DTI_v3.1.1.efs
          Attached Files

          Comment

          • #6
            SMI_Stochastic_Oscillator_v5.1.1.efs

            SMI_Stochastic_Oscillator_v5.1.1.efs
            Attached Files

            Comment

            • #7
              TSI_Ergotic_Oscillator_v3.1.1.efs

              TSI_Ergotic_Oscillator_v3.1.1.efs
              Attached Files

              Comment

              • #8
                Hi zMendel,

                Your most welcome.

                I don't have the Mesa studies either, so I still cannot run the efs, but I appreciate you posting the code.

                I didn't do anything to modify the drawShapeRelative() execution that I am aware of. I recommend that you should as a minimum add some debug statements back into the code. That will allow you to verify the different variables for null and that I did not introduce an error.

                Also, the getHour(0) and getMinute(0) commands are not that processor intensive. Since their values only change at the beginning of a new bar, you would save some resources by tracking them with global variables and limiting their execution to once every new bar.

                As for the drawShapeRelative() commands, each time they create a new shape, it adds an object to the screen that must be refreshed regularly. After you add 100 or 1000 new objects to the screen, the constant refreshing takes more and more system resources.

                Comment

                • #9
                  zmendel,

                  When I saw your post I thought the code look oddly familiar and then recalled those posts of a year ago. I see you found the Blau studies I recalled seeing in Alexis fileshare.

                  Glad to see how far you've gotten with the realtime trading, hope it's working well and thanks for sharing the code.

                  Is this strategy running ok in realtime and actually firing trades in realtime?

                  One thing I noticed that I always wondered about is that I didn't think the strategy methods were compatable with real time execution.

                  This strategy looks to be running once per tick and although you are checking for vRealtime to insure the generic broker calls are being made, statements like if Strategy.isLong() etc... unless I'm mistaken are getting executed each tick.

                  Not sure if that's the cause but it definately could be and having that extra overhead can't be a good thing. You may want to redesign those code blocks. I have code that I use if you are interested email me.

                  Keep on thing in mind, 25 % CPU your new Quad Core processor actually means one of the 4 processors is running at 100%. Because eSignal is a single threaded application it can only run on one CPU at a time. When that CPU is maxed out it will only show up as 25% in the task manager, so you are probably still looping.


                  BTW, coincidentially I was researching the Mesa Add On recently and a few others. What actual MESA add on is required to run the strategy? There were two, one was $150 and one was $40?

                  Do you run your strategies in tick replay before realtime trading, it's a very good idea before connecting to your broker?

                  FWIW I noticed depending on the circumstances that Alerts can also slow down a strategy significantly. You may want to try removing them if things don't run as planned.

                  Thanks and good luck,

                  Glen

                  [email protected]
                  Last edited by demarcog; 10-02-2008, 10:40 PM.
                  Glen Demarco
                  [email protected]

                  Comment

                  • #10
                    Hi zMendel,

                    Try this copy of the efs, I had to modify the lines with the getValue(-1) methods.
                    Attached Files

                    Comment

                    • #11
                      Looking Good

                      Steve:

                      This looks good.

                      In addition, it still runs much faster than my original code. Now it clocks in at about 1/10th the speed. (total time in MS = 16 for your code vs. 16172 for my original code). I suspect the percentage of reduced speed will range quite a bit when testing.

                      The true test will be real time which I will begin today. I will most certainly let you know how it goes.

                      It appears this will be very helpful to me. Thanks for you time and use of knowledge.

                      Regards,
                      zMendel

                      Comment

                      • #12
                        Hi zMendel,

                        Your most welcome, hopefully the improved efficiency will keep your resource usage down to manageable levels.

                        Comment

                        Previous template Next
                        Working...
                        X