Looks like an amazing project!

[edwinyzh]

How does it compare to the good-old, published-properties-only RTTI, and the new Extended RTTI in Delphi?

I guess it's something in between? That means, more feature rich than the traditional RTTI, but faster than the new Extended RTTI? I'm just guessing :)

[d-mozulyov]

Hello :)

The project has the following conceptual features:

• Standard types, including FreePascal, old and new versions of Delphi, convenient functions for managing them.
• Universal data representation, regardless of programming language and compiler version.
• Convert standard RTTI to universal data representation.
• Minimizing dependencies on heavy units like Classes, Variants, Generics, etc.
• Cross-platform functions invoke, including FreePascal and old versions of Delphi, creation of function and interface interpreters.
• Marshalling (serialization and deserialization of data) through different formatters: JSON, XML, FlexBin and others.
• Easy to use unit testing library that does not access the memory manager.

[edwinyzh]

@d-mozulyov Thanks for the details. What's the performance when comparing with the built-in RTTI?

[d-mozulyov]

In what cases are you interested in high performance?

[edwinyzh]

For example, I enjoyed using DuckDuckDelphi a lot but it uses Extended RTTI, and I had to abandoned it in some cases such as looping through an object list coz the performance is really really bad...

[d-mozulyov]

I specialize in optimizations. But I'm not sure that the library will help in your case, because I do not know your case. For me personally, the speed of serialization is important. I developed the binary FlexBin format, here you can see the preliminary results of the formatter for this format. The formatter has not yet been published, but over time it will become part of the library.

[edwinyzh]

Thanks for your explanation, I'm sure you are specialized in optimization :+1:

What's the intended use of this library, it's serialization and deserialization, right?

[d-mozulyov]

I have been working with RTTI for a long time and at one moment noticed that I lacked a universal solution. Therefore, I transfer part of the developments to the library and gradually expand them.

I have the following needs: scripti binding, serialization and testing.

[sglienke]

@edwinyzh I saw mentioned before that DuckDuckDelphi suffers from quite some overhead from enhanced RTTI - however working a lot with RTTI in my libraries I know that this is not often the case because certain operations that can easily be cached are done over and over again and thus are an issue in the library that used RTTI.

One example is the base class that automatically initializes its field depending on some attributes you put on them including creating classes for TStrings fields and alike - some third party library had this feature but did that with like half a dozen abstraction layers upon RTTI which turned this into some performance nightmare while I implemented a similar thing in Spring.TManagedObject which has a performance that is almost as fast as compiled code (because rtti is only read once and then cached in some highly optimized data structures)

[edwinyzh]

@sglienke thank you for your valuable comments, caching is a proven technique to improvement performance, I believe. But according to what I've read, such as the blog by "ab" the author of the mORMot framework, the new Extended RTTI actually slower than the old "published" RTTI, but I'd love to see more source and benchmarks if you know some.

That being said, If I would have some time and want to use duckduckDelphi again, can I'll see what I can improve the performance of it with the caching technique you mentioned, thank you very much for the hint.

PS, by "reading the rtti info at once", does spring4D do that at program startup? I find it will cause a near-one-second startup delay for a project that uses spring4d collections. spring4d is an excellent, but just like Generics.Collections, I kinda think the Delphi code editor/code completion/code insight doesn't match it due to the lack of support for generics and annon. methods...

PS2, Out of curiosity what the reason you have chosen bitbucket for hosting spring4D to begin with? I found it with github it's easier to communicate with each.

[sglienke]

I don't want to hijack this for discussing other matters - if you have questions regarding spring4d please ask them on our forum (link is in the readme.md) or contact me directly.

[edwinyzh]

OK, my fault :)

[edwinyzh]

You are definitely a nice Internet communicator :)

[d-mozulyov]

@edwinyzh

Please tell us what are your needs for RTTI and performance?

[edwinyzh]

OK, to sum it up, the reason why I found my interest in this project is that, I enjoyed using duckduckdelphi, because it's a great time-saver that allowed me to operate on a form like the following: Form1.duck.all.has('visible').sett(false); or duck.all.can('Clear').go; And although code like above won't suffer performance issue since it's an UI operation the the dataset is very small, it doesn't perform well with things like TList<TObject>, and without looking at the code I wrongly concluded the performance issue it has came from the Extended RTTI feature of Delphi, and thought your Tiny.Rtti project might be able to solve the issue of it. That's where my interests came from.

But as you see above, @sglienke said the issue can be solved using caching, and I trust him.

[d-mozulyov]

@edwinyzh

It would be great if you started developing the Tiny.DuckTyping unit. At the moment, Tiny.Invoke unit is being developed quite actively, which is designed to perform and virtualize functions. @sglienke absolutely correctly said that caching very much helps speed up the execution of commands. But other factors also affect performance. Searching for an identifier in a table, executing a function, changing a property. All this is planned to be accelerated as much as possible within the framework of Tiny.Rtti, Tiny.Invoke and Tiny.Properties units.

[edwinyzh]

@d-mozulyov , Tiny.RTTI has a great potential, but I'm not in a position to allowed me start that kinda of project yet :)

[d-mozulyov]

@edwinyzh

No problem. Stay tuned for updates (the next release will be in a few days). As soon as the opportunity arises, you can start developing Tiny.DuckTyping.