It would be maybe, if Object Pascal strings weren't already refcounted and copy-on-write that avoids a lot of copying and recreating when passed through the call chain, and the .NET a purely GC solution without the deduplicated immutable string table ducttaped on.
In the case of String(Lists)s sure, but for example when you use a temporary memory stream to dump a few kb into, this is pretty much uneccessary overehad.
Of course it does. At a given time not all allocated memory will be referenced by the program. And not all those tiny bits can fit any size program.
Depends on what you call fragmentation, because even though this memory might not be referenced anymore, it is still allocated, so you always have a continuous block of memory. In .Net (I think this does not work in Java) you can poke the GC to clean up, and at any point in time you only have one continous block of allocated memory.
A tstringlist has a fixed size, since the contained strings don't add to the class size. If it is used a lot, there might be dedicated freelist for it, making it fairly cheap to recycle.
But anyway, one can discuss from a theoretic viewpoint till the cows come home, but it the end it is all about benchmarking an application that has equivalent behaviour to your application
Doesn't all classes have fixed size? That said, I've already writte n a lot of classes like Lists, Hash- and Bitsets, etc. as advanced records for temporary usage. But sadly, as advanced records do not support inheritance, it sometimes a real pain in the neck to do so
Do all threads still halt on GC or has that meanwhile been fixed? I have been out of it for a good decade now, bar attending some Fosdem lectures.
Afaik there are a few mechanics in Android java that classical JVM java does not have. For one it might optimize the GC stuff completely away by detecting that an object is function local and puts it on the stack. Also the programmer can call the GC manually when the app is working anyway to not interupt the use flow. About threding, you can start a thread to be the "GC root", meaning for object created by that thread, the gc will only consider this thread (I think you can also relate other threads to it) so only that thread needs to be halted.
But take that information with caution, this is things I've learned about a few years ago, and I can of course misremeber, these information could be outdated, and I don't know which of those things are actually implemented in android and which where active research topics at the time that never made it into android. So I don't know this defenetly.
Which is exactly why I like pascal old school objects, because they live on the stack and it always feels like a complete waste of resources to create a TStringList for only one small procedure. But thats historic and we can't travel back in time and tell borland to do it any other way
I have started to write my own records/objects for such small tasks instead of using these classes
I already try to do this, but the problem is, the whole LCL and FCL infrastructure is built around common super classes (like TStream, TStrings, whatever) so very often it is just much more convinient.
Also, I really like the managed records, but as they don't support inheritance they are also pretty limited. And for some things you need to use classes, for example thanks to this bug:
https://bugs.freepascal.org/view.php?id=37164 which I encountered, using records as enumerator is completely broken as soon as managed types get into the mix (double free), but for-in is IMHO a prime case where objects are completely unecessary