Jakiś czas temu sporo walczyłem z pewnym napisanym przez siebie w C# softem, gdzie niemal w 100% byłem pewien obecności memory leak. Aplikacja to stosunkowo nieskomplikowany klient/serwer Modbus TCP odczytujący dane z kilku urządzeń i udostępniejący je klientom odpytującym w odpowiednich rejestrach dla każdego z klientow. Architektura stosunkowo prosta. Niestety sprzęt, na którym ów soft musi pracować to nieco leciwy komputer przemysłowy Advantech-a z 1Ghz Atom-em i 1GB Ramu pracujacy pod Win 7 32 bit. Po kilkudniowej walce z problemem i analizowaniem sytuacji za pomocą różnych profilerów nie udało mi się znaleść rozwiązania problemu. Garbage Collector co prawda działa i nie pojawia się „out of memory exception”, ale program zużywa niemal 75% dostępnej pamięci powodując konieczność częstego korzystania przez system z pliku wymiany i przy okazji dużego spadku wydajności pracy systemu a co za tym idzie i samej aplikacji.
Z jednej strony brak konieczności zarządzania pamięcia w .NET jest bardzo wygodny – z drugiej niemalże zerowa kontrola nad gargabe collector-em jest dość frustrująca.
Cała ta sytuacja była bodźcem do poszukiwań rozwiązania alternatywnego. Idealne wydaje się w tej sytuacji skorzystanie z C++, gdzie mam pełną kontrolę nad pamięcią i przy okazji tego typu aplikację mogę IMO lepiej zoptymalizować niż w środowisku zarządzanym. Problem w tym, że C++ (którego nota bene ostatni raz używałem dość dawno temu pisząc magisterkę – skryptowe dialekty c i c++ występujące w różnych narzędziach i urządzeniach automatyki przemysłowej do tego nie zaliczam) nawet z wykorzystaniem biblioteki standardowej jest duuuużo mniej wygodny w użytkowaniu niż C#.
Poszukując wygodnej biblioteki i środowiska trafiłem (po raz kolejny) na Qt. Do Qt miałem już kilka podejść przez kilka lat w ramach eksplorowania nowych technik i środowisk, ale nigdy jakoś nie wgryzłem się w temat – może po prostu brakowało mi odpowiedniej motywacji. Jak się okazuje był to spory błąd – gdyż Qt jest doskonałym i szeroko stosowanym, wieloplatformowym projektem.
Szczerze mówiąc jestem wprost oczarowany wygodą i (po opanowaniu pewnych charakterystycznych dla Qt – i IMO genialnych – koncepcji) łatwością użytkowania, mając nadal całą moc C++. Osoby znające Qt już od dawna pewnie teraz uśmiechają się pod nosem – „Amerykę odkrył” – ale przyznaję, ze jest to dla mnie spore odkrycie.
Z Qt (na chwilę obecną 5.3) otrzymujemy też świetne IDE – Qt Creator, z którego możemy skorzystać pod Win, Linuxem i Mac OSX. Na wszystkie te platformy możemy również targetować nasz kod. Poza świetnymi Widgetami, które oferuje Qt mamy również oparty na języku QML (coś pomiędzy XML a XAML znanym z WPF) Qt Quick, w którym możemy stworzyć pełną aplikację wykorzystując JavaScript lub połączyć Qt Quick z kodem C++. Aplikacje Qt Widgets jak i Qt Quick możemy również targetować naAndroida jak i na iOS, a w ostatniej wersji jest też działające wsparcie dla WinRT.
Jedyne czego brakuje, to możliwość stworzenia pełnej architektury sieciowej, w której Qt Quick wykorzystamy jako warstwę prezentacji danych w przeglądarce a po stronie serwerowej wkorzystamy kod C++ – ale nie wykluczone, że takie rozwiązanie w przyszłości powstanie.
W ramach testu, „przepisałem” z wykorzystaniem Qt aplikację odczytującą dane ze sterownika (przez libnodave) i rejestrującą do PostgreSQL. Stosując w zasadzie identyczną architekturę, udało mi się zejść z ok 1,1 sekundy jakiej potrzebowała oryginalna aplikacja w C# do odczytania danych i zapisania ich do bazy – do ok. 70 mS w przypadku wersji w Qt. Bez problemu udało mi się też uruchomić napisany kod pod Ubuntu.
Qt otrzymujemy na licencji LGPL. Oznacza to, że możemy stosować jedynie dynamiczne linkowanie i nie możemy (poza pewnym ograniczonym zakresem – szczegóły do znalezienia w sieci) wprowadzać zmian do samego Qt bez opublikowania kodu źródłowego owych zmian. Konieczna jest również wzmianka w dowolnym miejscu (chociażby w ReadMe) na temat wykorzystania Qt i licencji na jakiej jest oparte. Nasz soft wykorzystujący Qt nie musi oczywiście mieć otwartego kodu, może być też rzecz jasna w pełni komercyjny. Istnieje również mozliwość wykupienia od obecnego właściciela (Digia) wersji komercyjnej – ale ceny mocno odstraszają, visual Studio jest przy nich tanie jak barszcz.
W tej chwili rodzi się pytanie – „a co będzie, jak Digia, czy też ewentualny kolejny właściciel Qt, zrezygnuje z dalszego udostępniania Qt na LGPL”. Otóż twórcy Qt pozbywając się swoich praw do kodu podpisali umowę, na mocy której w momencie zakończenia przez właściciela biblioteki jej dystrybucji na licencji LGPL – zostanie ona opublikowana na licencji BSD.
Czy przesiądę się całkowicie z .Net na Qt ? – nie. Nadal większość naszych klientów używa Windowsa a wygoda programowania i znajomość .NET pozwala mi napisać soft sprawniej i szybciej. Wykorzystanie .NET jest też u niektórych klientów wymagane. Qt nie nadaje się również IMO na chwilę obecną do aplikacji webowych. Napewno jednak użyję Qt, jeżeli zajdzie potrzeba napisania wydajnej aplikacji, która będzie wymagała bardzo szybkiej i niezawodnej komunikacji. Zaletą Qt jest również pełna kompilowalność, a co za tym idzie nie ma potrzeby specjalnego zabezpieczania kodu – nada się więc bardzo do desktopowych aplikacji, które chcielibysmy zabezpieczyć i sprzedać masowemu klientowi.