Recently I had a chance to develop some applications on site. I used the greatly-productive Qt and Qt Creator, Application was built in an instant, and result was satisfactory. But the experience remained me some uncomfortable memory.
Except for skeleton codes, I put only 10 to 20 lines. I had to find out DLLs with more than 20MB, put them all to USB thumb drive, and I put the drive to PCs here and there. In each run I had to wait for 2~3 seconds more after starting running, and the delay became a burden as I repeated the job.
On Windows, Qt initiates DirectX and OpenGL, regardless of whether those modules are actually used in the application of not. My application was based fully on Qt Widgets and GDI, so that there's no way DirectX or OpenGL would be involved, but Qt initialized those stuff anyway. And to initialize, you have to wait for two or three seconds. If your system was already using those that's no problem, but in office environment, chances are that they'll be used only when you play video games, avoiding eyes of your boss.
Of course if the application is big enough to show splash screen saying "WAIT!" waiting for two or three seconds is no problem, but for apps quickly developed on site and run instantly, it's like forever - when you're busy and quick-tempered, chances are that you hit enter key a lot of times, resulting in starting a lot of instances at once, delaying the actual start more than ever(well, sometimes you experience Windows eats your keyboard or mouse input. don't you?).
Nowadays I feel that the high productivity and abundant features of Qt has its own tradeoff - e.g. performance issue(not only startup time, but also performance of features, like QLinkedList against similar others) and shared library. Of course in Linux the situation can be different, but in Windows it has its own story(if you're a GTK user that's yet another different story, but it's out of scope as for now).
Anyway, after experiencing this and that, I moved again from Qt to wxWidgets. I love the instant startup at cold start and freely available static link thanks to its license policy, resulting in easier deployment. There are, of course, some(expected) productivity losses or features not existing, but it can be overcome with the power of will(.....) and my own development.
I don't want to open the flame - Qt is really a great product and I totally agree. But there's no such thing as one size that fits to all. For some time being, I'll have fun with my wxWidgets and Code::Blocks.
A blog from a software developer who didn't get any formal training or education at all. :P
Friday, September 4, 2015
필요한 application의 현장 내 즉각적인 개발과 Qt
최근 현장에서 즉석으로 프로그램들을 만들 일이 있었습니다. 생산성 와방(......)인 Qt에 Qt Creator를 대동했습니다. 프로그램은 순식간에 만들어졌고, 원하는 결과를 정확하게 도출해냈습니다. 하지만 제게 그 경험은 일부 불편함을 남겼습니다.
Skeleton code를 제외하고 제가 작성한 핵심 코드는 약 10~20줄 남짓이었습니다. 그리고 전 20MB가 넘는 DLL들을 일일이 찾아 넣었고, 한데 모인 프로그램 패키지를 USB 메모리에 담아 각 PC에 꽂아가며 일일이 실행했습니다. PC에서 프로그램을 실행할 때마다 약 2~3초간의 지연이 있었고, 실행이 반복될수록 저 지연이 제게는 큰 부담으로 다가왔습니다.
Windows에서 Qt는 실행시 DirectX와 OpenGL을 기동시킵니다. 프로그램이 실제로 이 모듈들을 사용하는지의 여부는 상관없습니다. 제가 만든건 GDI 기반의 Qt Widgets 기반 프로그램이라 DirectX나 OpenGL이 끼어들 틈이 없었습니다만, Qt는 어쨌든 실행만 했다 하면 저 양대 그래픽 가속 시스템을 기동시킵니다. 그리고 저 모듈들은 최초 기동할때 최고 2~3초 정도를 잡아먹습니다. 이 모듈들이 이미 기동중이었으면 상관없지만, 사무용 PC 환경에서 저들 모듈이 기동하는건 팀장님 몰래 게임할 때(......) 빼고는 거의 없죠.
물론 splash screen을 띄워놓고 "기다리쇼"라고 할 정도의 큰 프로그램이라면 2~3초정도의 delay는 큰 문제가 되지 않습니다만, 현장에서 즉석에서 만들어져서 간단하게 쓸 프로그램에게 2~3초는 꽤 긴 시간입니다. 특히나 바쁜 상황일 경우, 성질 급한 사람들은 그 시간을 못 기다리고 엔터키를 연발하다가 instance를 수십개 넘게 만들어내는, 덕분에 프로그램의 실행이 더 지연되어 귀중한 시간을 낭비하는 상황까지 발생할 수 있습니다(뭐 사실 이런 사람들이 이해가 가기도 하는게, 가끔 보면 Windows가 키보드나 마우스 입력을 먹어버리는 경우가 있기도 하죠).
요즘 들어서 느끼는 거지만, Qt가 높은 생산성과 다양한 기능을 제공하는 이면에는 군데군데 발생하는 성능 이슈(꼭 cold start time이 아니더라도, linked list나 다른 여러 부분에서 미친듯이 속도가 느립니다)와 거대한 shared library가 있다는 생각이 듭니다. 일종의 tradeoff로 보고 있습니다만...... 물론 리눅스에서는 상황이 다릅니다만, Windows에서는 또 Windows만의 이야기가 있는 법이지요(GTK+ 계열 사용자시라면 또 다른 문제가 있을 것 같기도 합니다만, 그 부분은 다른 문제이니 여기서는 다루지 않겠습니다).
하여튼, 저런 상황을 겪고 난 이후 저는 또다시 Qt에서 wxWidgets로 옮겨왔습니다. Cold start시에도 instant로 번쩍하고 뜨고, 라이선스 정책 덕분에 static link에 대한 제약도 없어서 배포도 편합니다. 물론 구조적 특성상 생산성이 살짝 떨어진다거나 일부 기능이 없다거나 하는 문제도 있긴 하지만, 그 부분은 근성(......)과 직접 개발로 충분히 벌충할 수 있는 수준인 것 같습니다.
Qt는 정말 좋은 라이브러리입니다. 하지만 평양 감사도 저 싫으면 못하는 법이고, 모든 몸에 딱 맞는 하나의 치수를 가진 옷같은건 어디에도 존재하지 않지요. 당분간은 wxWidgets와 Code::Blocks로 연명하게 될 것 같습니다.
Skeleton code를 제외하고 제가 작성한 핵심 코드는 약 10~20줄 남짓이었습니다. 그리고 전 20MB가 넘는 DLL들을 일일이 찾아 넣었고, 한데 모인 프로그램 패키지를 USB 메모리에 담아 각 PC에 꽂아가며 일일이 실행했습니다. PC에서 프로그램을 실행할 때마다 약 2~3초간의 지연이 있었고, 실행이 반복될수록 저 지연이 제게는 큰 부담으로 다가왔습니다.
Windows에서 Qt는 실행시 DirectX와 OpenGL을 기동시킵니다. 프로그램이 실제로 이 모듈들을 사용하는지의 여부는 상관없습니다. 제가 만든건 GDI 기반의 Qt Widgets 기반 프로그램이라 DirectX나 OpenGL이 끼어들 틈이 없었습니다만, Qt는 어쨌든 실행만 했다 하면 저 양대 그래픽 가속 시스템을 기동시킵니다. 그리고 저 모듈들은 최초 기동할때 최고 2~3초 정도를 잡아먹습니다. 이 모듈들이 이미 기동중이었으면 상관없지만, 사무용 PC 환경에서 저들 모듈이 기동하는건 팀장님 몰래 게임할 때(......) 빼고는 거의 없죠.
물론 splash screen을 띄워놓고 "기다리쇼"라고 할 정도의 큰 프로그램이라면 2~3초정도의 delay는 큰 문제가 되지 않습니다만, 현장에서 즉석에서 만들어져서 간단하게 쓸 프로그램에게 2~3초는 꽤 긴 시간입니다. 특히나 바쁜 상황일 경우, 성질 급한 사람들은 그 시간을 못 기다리고 엔터키를 연발하다가 instance를 수십개 넘게 만들어내는, 덕분에 프로그램의 실행이 더 지연되어 귀중한 시간을 낭비하는 상황까지 발생할 수 있습니다(뭐 사실 이런 사람들이 이해가 가기도 하는게, 가끔 보면 Windows가 키보드나 마우스 입력을 먹어버리는 경우가 있기도 하죠).
요즘 들어서 느끼는 거지만, Qt가 높은 생산성과 다양한 기능을 제공하는 이면에는 군데군데 발생하는 성능 이슈(꼭 cold start time이 아니더라도, linked list나 다른 여러 부분에서 미친듯이 속도가 느립니다)와 거대한 shared library가 있다는 생각이 듭니다. 일종의 tradeoff로 보고 있습니다만...... 물론 리눅스에서는 상황이 다릅니다만, Windows에서는 또 Windows만의 이야기가 있는 법이지요(GTK+ 계열 사용자시라면 또 다른 문제가 있을 것 같기도 합니다만, 그 부분은 다른 문제이니 여기서는 다루지 않겠습니다).
하여튼, 저런 상황을 겪고 난 이후 저는 또다시 Qt에서 wxWidgets로 옮겨왔습니다. Cold start시에도 instant로 번쩍하고 뜨고, 라이선스 정책 덕분에 static link에 대한 제약도 없어서 배포도 편합니다. 물론 구조적 특성상 생산성이 살짝 떨어진다거나 일부 기능이 없다거나 하는 문제도 있긴 하지만, 그 부분은 근성(......)과 직접 개발로 충분히 벌충할 수 있는 수준인 것 같습니다.
Qt는 정말 좋은 라이브러리입니다. 하지만 평양 감사도 저 싫으면 못하는 법이고, 모든 몸에 딱 맞는 하나의 치수를 가진 옷같은건 어디에도 존재하지 않지요. 당분간은 wxWidgets와 Code::Blocks로 연명하게 될 것 같습니다.
Subscribe to:
Posts (Atom)