Yes, I am aware of the low trade volume since a few weeks. When the Bitfinex hack happened we got quite a lot of attention and volume (not really much compared to a centr. exchange though), but as expected people tend to forget quickly about security after a few weeks and return to centralized solutions for convenience (so we have to wait to teh next ahck, which will happen for sure 
- or the upcoming regulations next year…).
But beside that I think the lack of PR is the main problem (see comment on other thread).
And of course I am aware of the weaknesses in the app (usability, performance,…). But as my resources are very limited I need to focos on what is most important. And that will be the Synco (DAO) to get the bottleneck situation solved and that we are able to scale up.
I got reported mostly from Linux users that screensize issue but I expected that the huge majority already uses larger screens.
But to fix that and make the screen scrollable is on the long todo list. Its just not so easy (like in the main menu on the top) to get all the info layouted in such limited space…
But that is not a Java issue, its 100% my fault to have decided to not support smaller screens for the moment to save dev effort…
Java has a bad reputation from the early years (Java6, AWT, Swing) and from the over-engineering usually used in big companies using Java, but current Java is pretty ok IMO and it can be also very fast if done right (IntelliJ IDE proofes that - a huge complex IDE which feels like a native app, Bitsquare unfortunately not ;-( ).
There are 3 main known performance bottlenecks: UI, network code and BitcoinJ at startup or when syncing.
On the UI there can be improved a lot easily it just takes time and effort (what I don’t have atm), that’s why I am looking for a UI dev working on that (and fix stuff like the lack of support for smaller screensize).
On the network side it seems that the latest bigger update with tradestatistics has introduces some memory leaks or some other issues. But that is harder to locate and analyze and changes there are tricky as it is a complex, dynamic system.
It seems the (floodfill) network is too noisy atm, too many messages are propagated.
But that requires much care to fix. I changed recently some parameters to reduce that and then got problems that messages did not get well propagated.
It is very hard to test a P2P network or build simulations so that makes changes always risky (though I tested a few months ago with about 1000 offers and it worked fine).
On the BitcoinJ side it would need someone familiar with the codebase of BitcoinJ to check how and where it can be improved. I just fear that there is not much headroom. But that is mainly at startup or when syncing, which should not take too much time if the user regularily uses Bitsquare. To limit allocated resources for BitcoinJ so it will not use up 100% of CPU might be an approach though.
If you are interested to learn more about the P2P network there is an outdated document here available:
As said it is outdated but should give a basic overview about the concept and makes it probabaly easier then to dive into the code base. Specially the way how data is stored might need some background info.
