Jump to content

Stefan Glienke

Members
  • Content Count

    1365
  • Joined

  • Last visited

  • Days Won

    130

Posts posted by Stefan Glienke


  1. 5 hours ago, Marus said:

    If there is not enough memory or encounter other unrecoverable errors (because there are many reasons to fail) the thread stops and return the error.

    So you are saying that your app is already using more than 2GB (or more, large address aware and all that) and might not have enough space for allocating a simple string to store a file path in... But at the same time you are talking about using a form and showing information there... and where do you think the VCL (I am assuming you are using the VCL and not creating your form by directly accessing the winapi) takes its memory from?

    And worrying about the performance impact of try while scanning directories on the file system?

    Sorry, but this all makes absolutely no sense.

    • Like 3

  2. 1 hour ago, giomach said:

    I have also seen mention of a problem if the string exceeds the size of a pointer, so perhaps I must use the integer index rather than the actual string.

    Wait what? Well first of a string is basically a pointer so you could store that inside of the pointer - nobody is talking about storing the string content into a pointer - you could only ever store 2 or 4 Unicode characters in there. So yes, of course, it's about storing the string index into the pointer.


  3. 7 minutes ago, Willicious said:

    The above function does indeed decrement MyValue by 1, but it does so repeatedly when the function is called only once.

    Cannot be - if it's decremented by more than 1 then because the method was called more than once, simple as that.

    If the method is being called from multiple threads you need to use AtomicDecrement though.

     

    If you don't know from where the method is being called unexpectedly, use a data breakpoint on MyValue and the debugger will stop as soon as its being modified 

    • Like 3

  4. You could (ab)use the objects part of the first stringlist entries as index of the entry in the second stringlist 😏

     

    To be more serious - while the dictionary is a fair approach it leads to duplicated data which can make updating data more complex.

    To find a good solution it might be worth it to explain a bit more about the data and the use case itself. You also mentioned a TStringGrid for UI which I personally find a terrible component.


  5. As Dalija already mentioned some things that you need to do in a parallel environment add some overhead. This means that when the actual workload you are doing (such as incrementing a number) is so small that added overhead dominates the overall time. We all can agree that incrementing a number is not a suitable task to be executed in parallel. However, if you were to do some real-world tasks in parallel, there are still some things to consider - such as what has been discussed some while ago on StackOverflow, namely partitioning of data to process it in parallel properly.

    • Like 1

  6. 7 hours ago, David Schwartz said:

    when CPUs a year hence will offer a a 2x-5x improvement right out of the box with zero optimization.

    If it weren't for other statements already this one really disqualified you from even participating in any performance-related discussion.

    I just recently updated from an Ivy Bridge CPU to a Raptor Lake at home and the single-thread performance of some Delphi benchmarks approximately doubled.

     

    If you don't believe my sample then simply take a look at https://www.cpubenchmark.net/year-on-year.html

    You see that in about 10 years the single thread performance approximately doubled (and even less on server hardware).

     

    And when we think about how the real gains in performance are achieved these days (parallel computing) Delphi is even in a worse situation given the poor support for anything parallel computing (yes, it can be achieved but you need to handcraft a lot of code and much existing code does not scale well at all).

    • Like 2

  7. 21 hours ago, Kazantsev Alexey said:

    Two cent about compilers performance by the example of spritz-c stream cipher implementation:

    spritz_delphi_fpc.thumb.png.52229db9c54f36941644b11aa8ac9c81.png

    1. Delphi 11, Windows x86_64 (classic compiler), release

    2. Delphi 11, Linux x86_64 (nextgen, LLVM based compiler), release

    3. FreePascal 3.3.1, Linux x86_64, release

    Those Delphi Linux numbers are sad to see - but no surprise given how bad LLVM is being used (it basically lacks the IL opt step).

    Would be interested to see the difference between what dcc64 and fpc emit though - can do share the benchmark code somewhere?


  8. According to several sources, there are around 28 million software developers worldwide, give or take. I am highly skeptical that every 10th of them is a Delphi user. The number I have seen for C# is around 6 million.

     

    The 2022 Stackoverflow survey had around 3.5% of the participants list Delphi for the question "Which programming, scripting, and markup languages have you done extensive development work in over the past year, and which do you want to work in over the next year?" - C# has 28-30% mentioned in that list.

     

    If we check the 28mio software developers vs the 6 million C# users from some statistics with this percentage we see that this is somewhat realistic (30% of 28mio would be 8.4mio and 6mio out 28mio is around 21%). So we can assume that although Stackoverflow survey participants are not representative of the entire developer population we get kinda realistic numbers. If we assume that Delphi users were not overly invested in participating in the survey that leads us to around roughly 1mio.


  9. 47 minutes ago, Anders Melander said:

    Always? I haven't done my own benchmarking but I thought arrays also outperformed linked lists for the simple search+insert/delete case:

    https://kjellkod.wordpress.com/2012/08/08/java-galore-linkedlist-vs-arraylist-vs-dynamicintarray/

    (yes, I know it's about Java. potato, potato...)

    No, not always - that's why it says "Measure, don't guess".

    Anyway apart from being Java, that article is over 10 years old and things change - libraries get optimized (yes, even Java :classic_laugh:)

    I have no idea how the various pieces at play are implemented in Java - so why don't you simply run your own benchmark?

     

    I explicitly did not mention search but wrote insert or delete. I am well aware of the fact that access to contiguous memory is so much faster than random memory access that I know that if you add searching to the use case the more costly insert/delete can become totally irrelevant simply because the search is so much faster. Of course, usually, you don't just insert or delete to a linked list but also perform some search to determine the location where to insert or delete which is the reason why many benchmarks also include search.

     

    47 minutes ago, Anders Melander said:

    I mostly use linked lists for stuff like MRU/LRU caches, and only because I haven't bothered learning a more suitable structure (for caches, that is).

    I know a lot of literature mentions using linked list + hashtable but I would probably simply use a queue or deque that is backed by a circular array buffer.

     

    If there is anything to take away from the article you linked to then it is this:

     

    Quote

    However, doing the big O comparison is just pointless. Let me be repeat this:  It is pointless to compare algorithms that way.

    [...]
    Big-O notations tells nothing about how one algorithm fare against another algorithm. Big-O will only tell you how performance will degrade as n increases.

    This is because it completely ignores constant factors. Constant factors are why often the fastest algorithms and data structures, in reality, are hybrids that combine different algorithms. IntroSort is a good example that combines QuickSort with InsertionSort (for small sizes) and switches to HeapSort for QuickSorts worse cases. If you would ask "Which is better: QuickSort or InsertionSort?" Many people would say "QuickSort" but the the fact is that it depends on the number of elements. Similar to the question "Which is faster: a hashtable or linear search in an array?" Again it depends on several factors: the number of elements, the expense of comparison and hashing, and the actual implementation of the hashtable.

     

    And talking about the O(n) for inserting or deleting from a list. Here is a little benchmark and the results from Delphi 10.4 and 11.3:

    program BenchListInsertDelete;
    
    {$APPTYPE CONSOLE}
    
    uses
      Spring.Benchmark,
      System.Generics.Collections;
    
    procedure InsertDelete(const state: TState);
    var
      list: TList<Integer>;
      i: Integer;
      _: TState.TValue;
    begin
      list := TList<Integer>.Create;
      list.Capacity := 1000;
      for _ in state do
      begin
        for i := 1 to 1000 do
          list.Insert(0, i);
        for i := 1 to 1000 do
          list.Delete(0);
      end;
    end;
    
    begin
      Benchmark(InsertDelete, 'insert-delete').MinTime(2);
      Benchmark_Main();
      Readln;
    end.
    Delphi 10.4.2  
      
    ----------------------------------------------------------------------
    Benchmark                            Time             CPU   Iterations
    ----------------------------------------------------------------------
    insert-delete/minTime:2,000     223341 ns       223644 ns        11947
    
    
    Delphi 11.3
    
    ----------------------------------------------------------------------
    Benchmark                            Time             CPU   Iterations
    ----------------------------------------------------------------------
    insert-delete/minTime:2,000      41379 ns        41487 ns        68923

    You can guess why that is :classic_cool:

    • Like 3

  10. 57 minutes ago, Fr0sT.Brutal said:

    Who talks about indexing? Sometimes you have a raw buffer and have to search inside it for something or compare current pointer with something.

    I think this came as response to some general pointer-related comment and is quite OT to the original topic which was about linked list - but I agree - especially when dealing with string parsing and alike, naive code often is full of tiny substring allocations which could be avoided by similar approaches as .NET went with their Span<T> - using that throughout the runtime significantly improved performance in many areas. In Delphi code one typically uses PChar but that lacks a length limitation and routines that take that into account often have an additional len parameter which requires carrying around two distinct values which in fact belong together.


  11. 22 minutes ago, Kryvich said:

    @David Schwartz What type is ln, AnsiString or String? Try

    
    ln := StringReplace( strs[n], AnsiString('➤'), '>', [rfReplaceAll] );

     

    That would be quite nonsense given that strs is TStrings as David wrote ("strs points to a memo.Lines property").

     

    35 minutes ago, David Schwartz said:

    I don't want or need them in Unicode -- I want plain ASCII or Ansi Strings.

    Then don't use a Memo and its Lines property I would say - they are Unicode.

    • Like 1

  12. 5 hours ago, Rollo62 said:

    I personally think that ChatGPT is not great in complex coding, but can be a very helpful tool in creating Unit Tests probably, because this is usually a more routine work with several test cases.

    Many programmers dislike writing unit tests, because they think this is too much work, not worth the effort.

    I think that ChatGPT for creating unit tests be a great help too, because such code is typically not too complex, also probably convincing more and more people to make use of unit tests in the first place :classic_wink:.

    I have no experience with ChatGPT writing unit tests but there have been some other approaches explicitly for unit tests that are based on static code analysis because then it knows exactly what code to write to exercise all possible paths.

    For Delphi land that however is utopia since all the tools in these areas typically don't know anything about delphi/pascal.


  13. Looks to be yet another Bitbucket glitch - I have seen others report the same behavior recently and in the past. One more reason to move forward to another place rather sooner than later (99% sure it will be github which only lost to bitbucket back then because it did not have free private repos at that time).

    • Like 2
×