How to stop garbage collection?

  1. ‹ Older
  2. 3 days ago

    Eugene D

    Mar 25 Pre-Release Testers, Xojo Pro Canada scispec.ca

    @Björn Eiacute;ksson Xojo does not have "Garbage" collector. Its just simple reference counting. So when your objects reference count hits zero delete is called.

    Since this is not "Garbage collector" then you never have time consuming process going on that is taking time.

    Things working for you when global is simply because global variables never go out of scope so their reference count can never be zero.

    Thanks Bjorn. Knowing that there is not a garbage collector then greatly helps. There are delays in sending and receiving electronic signals back and forth. I will need to try a few work-arounds to see if there is something that will minimize timing delays in this language.

    Much appreciated

  3. Björn E

    Mar 25 Pre-Release Testers, Xojo Pro Iceland

    Such Electronic classes you should see as sort of "Async" classes so you need to ensure some object carries the ownership of tthe last reference until you are sure you no longer need them.

  4. Jürg O

    Mar 25 Pre-Release Testers, Xojo Pro
    Edited 3 days ago

    @Kem T You can implement your own garbage collection over reference counting, but how eat that might be will depend on the types of objects that are troubling you.

    This reminds me of this Thread: How to get rid of a Dictionary as fast and efficient as possible? .

    @Eugene D When Xojo automatically does reference counting to remove references, then this takes processor time away from electronics that communicate with timing.

    In the similar situation of the other Thread, a workaround is bypassing Xojo's Reference Counting and implementing an own "garbage collection". So let Xojo's Reference Counting destroy the no longer needed object at some time later (and/or in a background thread) when it fits the application's workflow best.

  5. Kem T

    Mar 25 Pre-Release Testers, Xojo Pro, XDC Speakers, MVP Answer Connecticut
    Edited 3 days ago

    I knew this sounded familiar. :)

    Another idea: Make your classes a subclass of a new GarbageCollector class. Its Constructor will add itself to a shared Dictionary. Periodically, or when you say, that Dictionary will be cleaned up by:

    1. Pulling the values into an array.
    2. Clearing the Dictionary.
    3. Pop each value, convert it to a WeakRef, then nil the variable that holds that object.
    4. If the WeakRef.Value is nil, it's gone. Otherwise, add it back to the Dictionary for next time.

    (Untested concept.)

  6. Eugene D

    Mar 25 Pre-Release Testers, Xojo Pro Canada scispec.ca

    I will try this concept.

    Thanks for the great answers everyone!

  7. Norman P

    Mar 25 Pre-Release Testers, Xojo Pro outside drowning sorrows

    @Eugene D Hello,

    I am working on some Raspberry Pi electronics projects and when Xojo does garbage collection (via reference counting) then apps that are doing sensitive timing have a large delay which prevents communication and/or causes logic errors in electronics.

    Workarounds are to not create new variables and declare all variables that are used as global. This helps a great deal.

    Does anyone know how to stop Xojo with garbage collection and/or reference counting?

    Thanks :)

    There is NO "garbage collection" - at least not in the same way that Java has
    When an items reference count goes to 0 it is immediately destroyed
    The only way to avoid this is to never have the reference count go to 0 - which means you retain everything always forever

    Now you _may_ have something like a module with an array of objects that has a factory methods.
    That factory method could just be the API that fronts a pool of existing objects.
    And those obejcts are never really released.
    Instead when you destroy one they just mark themselves as "freed" and then you can reuse them.
    The factory could track these and return any freed object before actually creating a new one.
    At least that way you slow the memory growth and you dont suffer any penalty from possibly freeing a top level object that refers to others and so on down a long chain of references that can take time to free

  8. Tim H

    Mar 25 Pre-Release Testers Portland, OR USA

    @Eugene D I have implemented my own garbage collection, and the issue that I am seeing is that Xojo is performing its own reference counting/garbage collection in the background that I have no control over.

    I think what you are seeing is the event loop that services the UI, sockets, keyboard, etc. This is very pronounced on Windows and occurs every 13 milliseconds or so, if memory serves.

    @Eugene D When I program in assembly, then I am not getting timing issues. I would prefer to use Xojo, and am curious to know if this is an option.

    In my opinion, no, Xojo is not a good choice for this.

  9. James S

    Mar 25 Pre-Release Testers, Xojo Pro

    I am curious what kind of thing you’re doing and what timing issues you’re seeing with this. I know that the older or smaller pi’s are not particularly quick in the CPU department but I’ve done lots of with with them and xojo and python and even C. I’ve never had a communications problem with anything from Xojo due to reference counting. But then I’ve also never tried to bit bang high frequency protocols out a GPIO pin or something like that. So perhaps what you’re trying to do is just beyond the easy reach of a userland app? I know that in order to do the really fast refresh code for certain individually addressable RGB led’s that people have resorted to actually writing kernel code in order to get guaranteed CPU time. If you need something like that then Xojo isn’t going to do it for you, but for anything at a more leisurely level of speed should happen OK reference counting or not. Do you have a lot going on in the destructor methods of classes? Or are you just dealing with so much memory and object usage that getting rid of them really does slow things down that much? If it’s really that bad on the Pi then perhaps there is actually a problem with the memory allocation philosophy on the Pi or on linux in general? That might be worth a bug report or an example project if you can show that returning memory to the system is taking unusually long in some circumstances. In any case I’m very interested in a little bit more info on what you’re doing, some vague numbers of the numbers of classes or the amount of memory you’re using an how long it is really taking to finish the release and come back to you code. There might be something actionable in there for Xojo.

  10. Eugene D

    Mar 25 Pre-Release Testers, Xojo Pro Canada scispec.ca

    @James S I am curious what kind of thing you’re doing and what timing issues you’re seeing with this.

    Hi James,

    I am seeing general issues from high frequency Bit-Banging (reading a pressure sensor with millisecond data), to communication with integrated circuits (the binary hand-shaking shows up with lower and higher duration times on my oscilloscope and prevents successful hand-shakes), to something simple like the timing on a stepper motor (slow motor turn rates and the motor stopping). Again, checking the oscilloscope shows the bits are not evenly spaced.

    Running the exact same programs on a competitive IDEs in other languages works well. Xojo programs on the Raspberry Pi work better when global variables are used and the performance is poor. Shrug, I don't know what else to say?

  11. Eugene D

    Mar 25 Pre-Release Testers, Xojo Pro Canada scispec.ca

    @Tim H I think what you are seeing is the event loop that services the UI, sockets, keyboard, etc. This is very pronounced on Windows and occurs every 13 milliseconds or so, if memory serves.

    Thanks Tim.

    13 milliseconds is a lifetime in some of this work. A logic-logic handshake will have a difficult time working with this large of a delay.

    Thanks!

  12. Norman P

    Mar 25 Pre-Release Testers, Xojo Pro outside drowning sorrows

    @Eugene D Again, checking the oscilloscope shows the bits are not evenly spaced.

    WHAT - no social distancing ?

    would splitting the reading part into a helper app improve thigns much (despite the work involved) ?

    what does this "other IDE" do that seems to make its app perform better ? maybe there's something to be learned from that ?

  13. Robert W

    Mar 25 Western Canada

    I'm curious what sort of bit banging is being done. My experience doing this has always involved a clock line and a data line, and variation in timing has never been a problem, as long as the clock and data line transitions occur in the correct order. I can see there would be a problem using a USART type serial interface with a single data line where timing is critical.

  14. Eugene D

    Mar 25 Pre-Release Testers, Xojo Pro Canada scispec.ca

    @Norman P WHAT - no social distancing ?

    Thats hilarious :) Thanks for the humour, I needed that.

    @Norman P would splitting the reading part into a helper app improve things much (despite the work involved) ?

    I haven't tried, and I could give it a try. It does seem like another workaround.

    @Norman P what does this "other IDE" do that seems to make its app perform better ? maybe there's something to be learned from that ?

    Most of these IDE's are just glorified text editors that have some simple autocomplete syntax for each of the languages. I am not sure if these IDE's do something special under-the-hood, as I am not exactly sure what Xojo does under-the-hood. Sure, I know the general things that are done with the IDE, and nothing seems extraordinarily special.

  15. Norman P

    Mar 25 Pre-Release Testers, Xojo Pro outside drowning sorrows

    @Eugene D I haven't tried, and I could give it a try. It does seem like another workaround.

    it is often whats available

    @Eugene D Most of these IDE's are just glorified text editors that have some simple autocomplete syntax for each of the languages. I am not sure if these IDE's do something special under-the-hood, as I am not exactly sure what Xojo does under-the-hood. Sure, I know the general things that are done with the IDE, and nothing seems extraordinarily special.

    [/quote]
    Sure - a lot of IDE's are JUST text editors and not a lot else really
    Guess what I'm wondering is what other languages ?
    Are we comparing a GUI app to a console app ?
    That alone could be a big difference

  16. 2 days ago

    Eugene D

    2 days ago Pre-Release Testers, Xojo Pro Canada scispec.ca

    @Norman P Guess what I'm wondering is what other languages ?

    The other two languages that works are C and Python.

    @Norman P Are we comparing a GUI app to a console app ?

    C was a console app, and Python was a GUI app. Xojo was also a GUI app. I haven't tried the C application in a GUI.

    @Norman P That alone could be a big difference

    I could try and write the application in Xojo as a console and see how that works. Thanks for the suggestion.

  17. Norman P

    2 days ago Pre-Release Testers, Xojo Pro outside drowning sorrows

    that would be a much more fair comparison I think

  18. 18 hours ago

    Wes W

    18 hours ago Pre-Release Testers, Xojo Pro MD, Columbia USA

    Would it make sense to off-load the time-critical work to a micro-controller like an Arduino and then have the Arduino pass the results to the Raspberry Pi? The Raspberry Pi isn't really suited to handling time-critical processing. But an Arduino is ideal for that kind of work.

  19. 17 hours ago

    Eugene D

    17 hours ago Pre-Release Testers, Xojo Pro Canada scispec.ca

    @Wes W Would it make sense to off-load the time-critical work to a micro-controller like an Arduino and then have the Arduino pass the results to the Raspberry Pi? The Raspberry Pi isn't really suited to handling time-critical processing. But an Arduino is ideal for that kind of work.

    Hi Wes,

    Yes, that is an option to have this work sent to an Arduino, and it works well.

    I guess the part that I have a difficult time with is that the programs work well with other languages and not with Xojo. The other languages 'just work' where I have to create work-arounds to try and make it work with Xojo. Don't get me wrong, I like programming in Xojo and the pesky work-around just get old after-a-while.

    If I will need to program the code in C for an Arduino and then send the data to the Raspberry Pi, why wouldn't I just use the same Arduino or use another more responsive language on the Raspberry Pi to do the same job. I was hoping for an easy answer to make it work in Xojo, that is all. :)

  20. Norman P

    17 hours ago Pre-Release Testers, Xojo Pro outside drowning sorrows

    @Eugene D I like programming in Xojo and the pesky work-around just get old after-a-while.

    they do

  21. 16 hours ago

    Robert W

    16 hours ago Western Canada

    That's the price you pay for having the convenience of a do-everything framework at your fingertips.

    I mentioned earlier that almost all of the chips that I have to communicate with are standard clock line plus data line interfaces which are not timing critical, and will communicate reliably with all kinds of random delays in the signals. If you're using a device that has strict timing requirements, then even if you manage to eliminate the garbage collection delays in your Xojo app, there's still the operating system to deal with. It has its own housekeeping tasks that could conceivably create timing problems.

    For the one application where I did have to communicate between a Xojo application and a device with a serial UART interface, I did as Wes suggested: a small Arduino compatible ESP8266 go-between, converting serial data from the field instrument to TCP/IP via wifi to the Xojo application.

or Sign Up to reply!