Hi Julian, I thought you had thought of using Haskel for generally specifying the driver logic, or was that a misunderstanding on my side? Did you want to also have the POJOs and the Serialization/Deserialization in Haskel? If yes, this shouldn't be a problem. We could simply generate a language template for Haskel in this case.
I am currently using a ReadBuffer and a WriteBuffer, which the generated code expects to be present. This is currently test-java-s7-driver module, but will move that to a "java-dirver-base" module (or something similar). Chris Am 05.06.19, 17:05 schrieb "Julian Feinauer" <[email protected]>: Hey Chris, what do you mean? I suggest to have a Language specific „native-lib“ which would be netty based in the case of Java. This should all be hidden behing a „Buffer“ Interface (similar to nettys, perhaps a bit less…). Julian ________________________________ Von: Christofer Dutz <[email protected]> Gesendet: Wednesday, June 5, 2019 10:08:56 AM An: [email protected] Betreff: Re: [CodeGen] Performance values Hi all, In the train today I'll be working on the serialization (Which will be a challenge) But I am sure this will be a lot of hard work but also a great step forward. Is there any progress on the Driver-Logic generation front? Otherwise I would probably try to whip up a hand-written Netty layer using the generated model. Without all the parser/serializer code this should only be a fragment of the existing driver code. Chris Am 05.06.19, 09:59 schrieb "Strljic, Matthias Milan" <[email protected]>: Hura sounds nice 😉 I hope I find time to play a bit around with it in the next few days. Greetings Matthias Strljic, M.Sc. Universität Stuttgart Institut für Steuerungstechnik der Werkzeugmaschinen und Fertigungseinrichtungen (ISW) Seidenstraße 36 70174 Stuttgart GERMANY Tel: +49 711 685-84530 Fax: +49 711 685-74530 E-Mail: [email protected] Web: http://www.isw.uni-stuttgart.de -----Original Message----- From: Christofer Dutz <[email protected]> Sent: Tuesday, June 4, 2019 4:16 PM To: [email protected] Subject: [CodeGen] Performance values Hi all, so as I mentioned in Slack yesterday I was able to successfully parse a S7 packet with the code generated by the code-generator. There I am using Apache Jexl for evaluating the expressions we are using all over the place. It got things working quite easily. However my gut-feeling told me all these Jexl evaluators I’m creating can’t be that ideal. But not wanting to pre-maturely optimize something that’s already good, I did a measurement: So I did a little test, in which I let my parser parse one message 20000 times. It came up with an average time of 0,8ms … this didn’t sound too bad compared to the about 20ms of the interpreted daffodil approach. But is this already good? It’s probably not ideal to compare some results with the ones we know are bad, instead I wanted to compare it to the ones we are proud of. In order to find out I whipped up a little manual test with the existing S7 driver. For this I simply plugged the 3 layers together with an Embedded channel and used a custom handler at the end to return the message. This seems to work quite nicely and I was able to run the same test with the Netty based S7 driver layers we have been using for the last 2 years. The results were: Parsed 20000 packets in 796ms That's 0.0398ms per packet So this is a HUGE difference . As one last check I ran JProfiler over the benchmark and it confirmed that 87% of the time was used by Jexl. However the creation of Jexl expressions, not their evaluation. So one optimization I’ll try is to do, is to have the expressions created statically and then to simply reference them. This will increase the complexity of the template, but should speed things up. And I’ll also change the code I’m generating for the Type-Switches to work without jexl. Simply assuming this would eliminate the time wasted by jexl (great simplification), we would reduce the parse time to 0,1ms which is still about 3 times that of the existing driver. I am assuming that this might be related to the BitInputStream I am using … but we’ll deal with that as soon as we’re done with getting rid of the time wasted by Jexl. So far an update on the generated-drivers front. Chris
