Jump to content

Lars Fosdal

Administrators
  • Content Count

    3343
  • Joined

  • Last visited

  • Days Won

    111

Posts posted by Lars Fosdal


  1. We always run with MARS=Yes.

    We also follow a different pattern with regards to inserts and updates - using stored procedures to change the contents of the database.

     

    Usually the problem is that more than one operation is attempted on the same connection at the same time.

    Are you certain you are not crossing variables somewhere? In you example code, there is fdcAmman and fdcUpdateAmman ...

     


  2. I use EL, so I can't really opinionate on MadExcept.  It is very rare that it gives me no clue to the callstack for exceptions caused by dangling pointers, but when desperate, I've turned to using a FreeAndNil overload to set the pointers to a recognizable value, $DEAD0001 and so forth, and logging the line where I set the respective ptr values to at least find a hint to the context that is trying to use it. Problems like these can be a pain to find.

     

    Another alternative would be to try with regular threads to see if the problem persists - if it doesn't, it might be that you can attribute it to something OTL specific?

     

     

    • Like 1
    • Thanks 1

  3. 1 hour ago, Tommi Prami said:
    1 hour ago, Lars Fosdal said:

    No locks or semaphores in CompressFile?

    Yes but released in  try.. finally. I use Critical section and very short ones. 

    Doesn't that mean that only ONE compression can happen at a time - i.e. serializing your use of CompressFile?
    Edit: Are you reusing the same critical section in multiple locations in the code or on multiple nested levels? That could become a race condition.

     


  4. 3 minutes ago, Stefan Glienke said:

    what you refer to is AOT - when .NET code runs, the runtime always JITs the code to machine code

    Regular C# .NET Code transpiles to IL code. When you run, the JITer compiles the IL code to native code - but as you say - on every run.
    But - You can - with limitations - compile C# .NET code to native code - using the AOT approach.
    From the second link I posted:

    Quote

    Publishing your app as Native AOT produces an app that's self-contained and that has been ahead-of-time (AOT) compiled to native code. Native AOT apps have faster startup time and smaller memory footprints. These apps can run on machines that don't have the .NET runtime installed.

    There are some elements that are still JITed - such as LINQ expressions - and there is a limit to which libs and platforms that supports AOT - but it keeps expanding from one .NET version to the next.


  5. Something that is often overlooked is to limit the redraw frequency. If you redraw the display on every update and there are many updates per second, you may save a lot of time on triggering the invalidate at a capped rate, i.e. not do a full redraw every time, but update once every fixed time interval.  Unless you are doing video processing - a redraw at maximum twice per second should be more than sufficient?

    • Like 2
×