Investigate ways to reduce memory usage & startup time on readers

[theOperand]

There are three options to reduce startup time and memory usage of the readers:

• Use a separate JVM, e.g. OpenJ9 (openj9.org) or other alternatives. However, OpenJ9 for ARM is still in beta!
• Look up tuning options for the JVM to reduce memory usage or startup time. Probably possible but needs investigation (and config)
• Rewrite in a language that isn't Java, e.g. Go, Python, Rust...

[RockinRoel]

I think there are also ways to make a more lightweight Java with jlink: https://www.baeldung.com/jlink

I think that's more applicable to more "modern" Java applications that actually use modules, though. I don't know if that's very effective with the LTKJava dependency, which is kind of an old dependency.

I don't know if GraalVM can do something for you? I guess since you're still using old Raspberry Pis you'd need 32 bit ARM support, or you would have to upgrade to more modern Pis (which might help the startup time issue as well 🙂).

[RockinRoel]

As for your third bullet point: the issue is really that you'd need something that can talk LLRP.

[bertvandepoel]

It seems, surprisingly, that quite a few people have reimplemented LLRP in all kinds of languages. While discussing this, we found out that there are 4 different implementations in Go (though we haven't checked the quality). It seems Impinj's choice to leave LTK dormant has motivated people to work on their own libraries. But regardless it's still very much up in the air.

[RockinRoel]

Yeah, I did some googling after I posted that comment, there's indeed more options now. Of course, no idea about the quality either. Some of them seem to use the same generating code from XML specs strategy.

[theOperand]

Generating code based off XML is also the method used for the official LTK libraries, so there is some merit to it. If we don't want to use third party libraries we could always opt for C++ or even Perl, as those also have official libraries.

…

On Mon, Aug 2, 2021, 22:20 Roel Standaert ***@***.***> wrote: Yeah, I did some googling after I posted that comment, there's indeed more options now. Of course, no idea about the quality either. Some of them seem to use the same generating code from XML specs strategy. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#34 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6KUIP6JB7H4ZGZL2MD6FDT234ZNANCNFSM5BNKFS3A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[RockinRoel]

Generating code based off XML is also the method used for the official LTK
libraries, so there is some merit to it.

Yeah, the thing that ultimately makes LTKJava a difficult dependency to deal with is not all of the code that was auto generated from the XML, but rather all the networking underpinnings, things that may probably work with APIs that are built into Java nowadays. I imagine a language like Go already has good async networking APIs (I don't know much about Go but I think two major features that a lot of things revolve around are channels and goroutines, right?), so I can totally see that working.

Of course with native compilation you do have to consider how you're going to compile it, and whether you have an easy to use toolchain to cross compile to a Raspberry Pi. You could also compile on a Raspberry Pi, but that may take a while.

If we don't want to use third party libraries we could always opt for C++ or even Perl, as those also
have official libraries.

Yeah, I did put a little work a while ago into updating the C++ version, getting it to build with CMake: https://github.com/RockinRoel/LTK/tree/master/LTKCPP

I don't know who's going to end up maintaining the software, of course. It may be harder to keep finding people with C++ experience. Again, cross-compilation, while very doable, takes a little bit of figuring out here too.

You could very easily rewrite the software for the reader in whatever language you want. Every part happens to be written in Java right now, but I did make it so that all the individual parts just communicate with JSON messages over Redis, so they're interchangeable. The readers don't ultimately need to be able to do much. You may even be able to manually implement the few data structures that you're actually using rather than relying on some LLRP implementation.