Leaderboard

I'm not sure what problem you need to solve, but for me, UTF8 works well under all platforms. Honestly, I have not checked for any UTF8 compatibility issues on the different platforms, because I use my own translation system. Did you find any specific issues with UTF8, do you have an example ?

thank Dave Nottage and Rollo62. It was ok for both iOS and Android

Why are you using two TStringLists, and not a single TStringList that holds 'name=value' pairs? Or, at least a TList that holds TPair<String, Integer>? If you insist on using TStringList, then I would store the indexes of the 2nd list in the Objects[] property of the 1st list. That way, no matter how the 1st list is sorted, the indexes will still match up.

Those two methods you have don't do the same thing. If you take a look to the result of the calculation, you will see that results are different. First method will increment sum 1000000 times and second will increment temporary value 1000000 times and then add that temporary result to the total sum 1000 times. So the second method runs more operations and that is why it runs slower. If you correct the code to calculate exactly the same sum in the second method, you will see that this one will run faster. for ThreadedI := 0 to Pred(1000) do begin Inc(ISum); end; Number of tasks running in both cases will be the same, but the second method has the advantage because the temporary calculation is not using interlocked operation which is costly, and only uses it to add that temporary sum to the final result. Overall, Parallel.For code will run interlocked operation 1000000 times, and task based method only 1000 times.

See also

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.

I noticed the grin... but there are plenty of people that don't know how Meta voting works, so I explained just in case, for anyone reading this.

Stack Overflow annual survey is live. You can find more info at https://meta.stackoverflow.com/questions/424565/complete-the-2023-developer-survey

Yes, because interlocked operation are expensive. Multithreading always comes at a price. The code is more complicated, you need to pay attention to thread safety and it will generally run slower than single threaded code. Not every operation is worth doing in parallel. If some calculation takes longer time, you can run it in single background thread, so you can keep your application responsive, but for splitting some task to multiple threads, you need to make sure that the task can be successfully parallelized and that performance gained is significant enough. For any operation that runs less than a second, it is usually not even worth to start a single background thread, let alone starting multiple ones.

You don't want a server and DB but local copies, I can understand that, but even for MQTT you need a server somewhere (or I missed something ?). It's interesting to know if you want to synchronize notes as texts (last update erase the others) or synchronize changes on notes. Two different approaches. If it's text, you can use a private git repository and an API over it. Is your app a personal app or is it distributed (and you don't want to manage users datas) ?

Perhaps these notes from Dave were useful here as well: https://en.delphipraxis.net/topic/8065-how-can-i-handle-the-javascript-result/?tab=comments#comment-68093

It's possible that some stack unwinding does occur, but the call stack you provided earlier clearly shows that the exception handler makes a bunch of function calls, which could easily eat up whatever stack space was freed up. Pretty much, yes. A thread has a fairly limited call stack available to it. The stack can grow only so much before it overflows. That is why it is not a good idea to put a lot of data on the stack in the first place. However, you can set the limits in the project options, if you need them higher. Just know that doing so can affect all threads created at runtime (unless overwritten in code on a per-thread basis).

As per the documentation, you do not create an instance of WKScriptMessage, and in any event, you cannot descend from TWKScriptMessage anyway. Also as per the documentation it is used when you implement custom Javascript message handlers. What you could do is use the evaluateJavaScript method of WKWebView and pass to it a completion handler, which could be declared on your main form like this: procedure JavaScriptCompletionHandler(obj: Pointer; error: NSError); ..and implement it like this: procedure TfrmMain.JavaScriptCompletionHandler(obj: Pointer; error: NSError); var LJavaScriptResult: string; LCode: Integer; begin if obj <> nil then LJavaScriptResult := NSStrToStr(TNSString.Wrap(obj)) else LJavaScriptResult := 'null'; if error = nil then LCode := 0 else LCode := error.code; // Do something with LJavaScriptResult and LCode, here end; Call evaluateJavascript like this: LWebView.evaluateJavaScript(StrToNSStr(AJavaScript), JavaScriptCompletionHandler) Where LWebView is a reference to the WKWebView in the iOS implementation of TWebBrowser

The 32 bit behaviour is preferable. Why do you want to do anything after a stack overflow?

Perhaps it's because x64 parameters are stored in registers instead of on the stack. Could you check the assembly code and add more parameters to see if x64 fails as well?

TL;DR; There was a scripting solution from freeonterninate: ScriptGate https://bitbucket.org/freeonterminate/scriptgate/src/master/ I don't use this currently and this is quite old, so I would bet it's not working anymore with current TWebBrowser. Maybe it will be helpful anyway, and you might get this working (again ?). Would be great to get some feedback on the status of this project.

I started actively using databases in the past couple of years in my applications, and these are the things I wished to know from the beginning: - Every SQL thing should be in a separate thread. If connection takes 20 seconds or you are downloading a very large dataset over a slow connection, your application will be frozen. Publish important data or the complete dataset objects as properties. Just make sure you disconnect all datasources before any operation and reconnect them after, as data events will start to fire off in an inconsistent state causing AVs most probably. - When it comes to threads, a golden rule is that each thread should have it's own connection to the database. You also want to make sure that threads are working with different tables or you should have correct transaction isolation set up. - For service applications I wrote my own "ORM", which is basically a wrapper for a TQuery. Each field the query returns are published as typed properties. So instead of query.Edit; query.FieldByName('field').AsString := 'Hello, world'; query.Post; I simply can say: myTable.Field := 'Hello, world'; and myTable takes care of everything else. I took this one step further after a couple of DB changes and wrote my own planner. I tell it what kind of tables and fields I want, and it generates MySQL and MSSQL create and delta scripts AND all the myTable classes as Delphi source files. I make a change, I have all the SQL scripts ready to ship with the update and I already can use the new fields in all of MyTable objects... you get the point. - Depending on the component you use (and how they access the databases) client libraries might not be thread safe or requiring special parameters upon establishing the connection to be thread safe! I found it as a best practice for example to have a critical section when connecting as I had strange access violations when 7 worker threads tried to connect using the same library at the same time. - If performance is critical, do not use TQuery.FieldByName. That's all I can think of for now but I'm sure I missed a few. If anything else pops up, I'll try to remember to update this thread.

A post with that many downvotes is usually closed... ...just sayin'.