Just run an analysis of 1M Eager run to see malloc profile - can see a number of nice multiples of 1M small allocations, adding this issue as a placeholder for digging into if some could be eliminated (even though it is just transient allocations, they seems to be the root cause holding back performance).

Attaching screenshot from run.

Some start on polish for: https://github.com/mzaks/FlatBuffersSwift/issues/55 https://github.com/mzaks/FlatBuffersSwift/issues/75

for your consideration - if you are ok with the direction, I will spend some more time on it.

Creating this as a reminder:

It would probably make sense to make a final API cleanup iteration when 'all' functionality is in plac3 considering https://swift.org/documentation/api-design-guidelines/ for even nicer 'swiftyness'.

How would you like to approach this, using a branch, or simply going ahead in master?

Expecting new shiny tools tomorrow due to WWDC...

Personally, I wouldn't mind migrating to S3 in master as things are still a bit in flux (and preferably looking at support for the package manager), but doing a swift3 branch is also more than completely fine of course. Thoughts?

Also related to #55.

Ok, I had a look at the thread safety of the current pooling - and its a mixed bag...

1. Currently the reader&builder pools are not safe to be used from multiple threads - tried to fix it and added the most lightweight synchronization I could find (objc_sync_enter/exit) and it has a significant impact on the streaming test.

Pooling is still clearly beneficial, but if adding the sync, it is a definite issue hampering performance.

1. The general instance pools are safe to be used from one thread per instance-type (that is, if one had two different .fbs they could be used in parallel from two threads, as the caches are separated per type) - but it is in general the same issue as above

To summarize Enabling the pooling has a significant improvement for single-thread usage Adding naive synchronization kills much, but not all of the advantage of using builder&reader pools Adding it seems to completely kill table instance pool improvements

Next steps

1. Can address it either by documenting allowed usage of pooling (with more formal constraints on what is allowable and possibly looking at restructuring/alternate API).
2. Alternatively, we can add synchronization and always be safe (but significantly slower).
3. Thirdly, we could have two possible modes so one must explicitly enable multi-thread mode.

I'll see if I can find any more suitable solutions but would be interesting to hear your thoughts @mzaks.

I would probably personally lean toward 1 or 3 (or a combination thereof), as pooling is opt-in, one can always choose not to use it - for those applications that only access the data model from the .fbs from one thread, it really does help, but I think it is important that the out of the box behavior is safe but one can opt in.

#46 shows that by using structs and direct reading from buffer we can achieve fast performance with nice API. Getting rid of FlatBuffersReader should also benefit the eager implementation without the need of instance pooling. The FlatBuffersReader.swift file should only contain the pure functions and no class definition.

I had a look at implementing the benchmark used by google for flat buffers using the .fbs from https://github.com/google/flatbuffers/blob/benchmarks/benchmarks/cpp/FB/bench.fbs

This yielded an empty struct 'Foo' when processed thusly:

`solid:FlatBuffersPerformanceTestDesktop jocke$ java -jar ../fbsCG.jar -fbs bench.fbs -out bench.swift -lang swift ERROR (org.eclipse.xtext.diagnostics.Diagnostic.Syntax) 'mismatched input 'id' expecting '}'' on Struct maxim.zaks.flatBuffers.impl.StructImpl@3301500b (name: Foo), lineNumber 25, length 2

'bench.swift' has been generated. `

Attaching the generated swift file as well. bench.swift.txt

I believe the scheme must have a root object that is a table?

It would be nice to optionally generate a struct also for the top level for small payload messages where by value semantics would be desirable. An option for the codegen to generate a struct for the root object would be nice to support this.

There are 3 ways to access data from binary:

• Class.fromByteArray(),
• Class.LazyAccess()
• and Class.Fast().

The wiki explains that the whole object is not deserialized by using LazyAcess. But what about Fast? How does it differ from the others?

It'd be nice to document somewhere the differences between them.

Anyway, thanks for your work! 👍

See commit comment https://github.com/hassila/FlatBuffersSwift/commit/017740e97039d19334b2396b8eb464ec5add321a for details, but the TL;DR, "10% encoding performance by optional manual reuse of builders + added raw access to buffer data when needed".

bench.swift diffs outlines the minor codegen changes needed to support it.

Hey, at first thank you a lot for providing Flatbuffers support in Swift, I really like the library.

Currently I have an issue where I am using a Union type but I am not able to decode the Union type correctly.

Flatbuffers file:

table A {}
table B {}
union Test {
  A,
  B
}

table Root{
  test:Test;
}

 if let test = root.test {
  switch test {
  case let test as A:
    print("A")
  case let test as B:
    print("B")
  default:
    print("none")
  }
}

If I try to convert test as A or B I get the following error message: "Cast from 'Test' to unrelated type 'A' always fails" and it indeed fails and it prints "none". Do you have a suggestion why this could be the case?

I am using Swift v4.2

Thanks in advance :)

Hello,

I woiuld liek to understand on which spec of Flatbuffer (flatc) compiler is the current implementation based on? I cannot find any such information or maybe I am missing something. Can someone please give some pointer?

Basically Current Flatbuffer & flatc gen is 1.11.0 and what is this repo generates the code?

union Character {
  MuLan: Attacker,  // Can have name be different from type.
  Rapunzel,         // Or just both the same, as before.
  Belle: BookReader,
  BookFan: BookReader,
  Other: string,
  Unused: string
}

Hi Maxim, I really like the concept of FlatBuffers 😍 With Swift 4 you can create your own Encoder and Decoder to support the new codable feature of Swift 4. This will allow FlatBuffers to be used on a larger scale. Here some resources to help you:

• An example implementation of Swift.Codable using a simple binary format (Mik Ash)
• Ultimate Guide to JSON Parsing With Swift 4 (Ben Scheirman)
• Encoding and Decoding Custom Types (Apple)

FlatBuffers should also be available on most environments. For that it would have to be a cross-platform component. 😉 To create a cross-platform component your can follow my tutorial Swift Cross Platform Framework or directly use my tool XcodeTool - Create a new component cross-platform