Recent

Author Topic: A record-based TFileStream alternative with better performance and a nicer API.  (Read 2084 times)

Akira1364

  • Hero Member
  • *****
  • Posts: 539
This is just something I've been working on over the last few days:

https://github.com/Akira13641/TLightFileStream

Handoko

  • Hero Member
  • *****
  • Posts: 3237
  • My goal: build my own game engine using Lazarus
Great, I can use it in the future.

I saw you used the Pascal modern syntax, which is the thing I'm unable to understand. I can learn from your code. Very useful.

Thank you for sharing the code.

Alextp

  • Hero Member
  • *****
  • Posts: 901
    • UVviewsoft
Indeed, it is interesting code. And Class.Proc.Proc.Proc in example is nice.

BeniBela

  • Hero Member
  • *****
  • Posts: 687
    • homepage
I like that design. Classes were a mistake. All of fpc should be rewritten with record/objects.

If NOCHECKS was called something LightFileStream_NOCHECKS, it could be enabled globally in someone's project, without potentially disabling checks in unrelated units.

Unfortunately this is not as fast as it could be, since fpc keeps fields like FHandle on the stack, even if it could keep it in a register, when everything is inlined

If there were TFileStream compatible methods like function Write(const Buffer; Count: Longint): Longint; and the TLightFileStream was an object, one could write through a method pointer @write, and switch between TFileStream and TLightFileStream polymorphically,
 

Thaddy

  • Hero Member
  • *****
  • Posts: 9292
Indeed, it is interesting code. And Class.Proc.Proc.Proc in example is nice.
This is almost like KOL syntax, which also uses the PSelf function chaining approach since almost 20 years. It is nothing new, but a very useful programming technique.
@Benibela
Look at KOL for similar techniques based on old school objects. In fact it does all you describe. Again nothing new.

But the code looks good and seems fast.
« Last Edit: March 12, 2019, 08:51:31 am by Thaddy »
also related to equus asinus.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 7623
Why const x : byte ?  On some architectures that might be by ref.