Pages

Sunday, May 2, 2021

When Python Language Server is too slow on Qt Creator(Windows)

Nowadays I'm teaching Python to my son. After teaching stuff I found out that now it's the very timing to teach how to use GUI. And what? For me tkinter is too "weak" and I decided to use Qt, which is one of my favorite "weapon."

So I tried Python on Qt Creator. And guess what? Suddenly LPS became the "black sheep." Ctrl-Space doens't work, and according to messages from LPS it takes a few minutes to follow me up for my 3-second typing...... Frankly speaking I was fully disappointed. Does Qt Creator just ignore Python users, though Qt Company says that it officially supports Python?

However, even it was kind of...... strange. If all the users experience the same symptoms like me, then the forum would have already been highly flamed,  but I couldn't find anything.

Well, and all of sudden, I encountered a solution.

  1. Go to Options and select Language Client
  2. Select Python Language Server
  3. Change Startup behavior from Requires an Open file(default) to Start Server per Project
  4. PROFIT!!!

I have no idea why, but now I'm satisfied with overall performance and result. With default configuration from Qt Creator practically I couldn't do anything so that I seriously considered Visual Stuio Code + Qt Designer, but now with Qt Creator on full throttle, I don't have to go workaround

Hope that this small tip helps those who want to develop in Python with Qt Creator.

Qt Creator(Windows)에서 Python Language Server가 너무 느릴때의 조치방법

그러니까...... 아들녀석에게 Python을 가르치다 보니 GUI를 가르칠 타이밍이 되었는데, tkinter는 (최소한 제 입장에서는) 뭔가 너무 많이 빈약해서 제 장기(?) 중 하나인 Qt를 가르치는게 더 낫겠다는 생각이 들더군요. 그래서 Qt Creator를 사용해서 Qt for Python을 가르치려고 했는데, LPS가 너무 느린겁니다. Ctrl-Space는 동작하지도 않고, LPS에서 뿌리는 메시지를 보면 제가 3초만에 친 타이핑을 쫓아가는데 몇 분 이상이 걸리고...... 하여간 대단히 실망스러웠습니다. Python을 공식적으로 지원한다고 해 놓고 정작 Qt Creator에서는 Python 사용자들을 거의 방치하는 건가 하는 생각까지 들더군요.

하지만 한편으로는 그것도 꽤 이상했습니다. 만일 모든 사용자들이 나와 똑같은 상황이라면 분명히 포럼이 쌩난리였을텐데 왜 이렇게 조용하지?

그런데 의외의 지점에서 해결책이 나오더군요. 제가 찾은 해결책은 이렇습니다.

  1. Options에서 Language Client를 선택합니다.
  2. Python Language Server를 선택합니다.
  3. Startup behavior를 "Requires an Open file"에서 "Start Server per Project"로 변경합니다
  4. 끝!

왜 그런지는 잘 모르겠지만 하여간 이렇게 하니 만족스러운 속도가 나오더군요. 사실 Qt Creator의 기본 설정만으로 작업하려고 했을 때에는 전혀 답이 나오지 않아서 Visual Studio Code + Qt Designer 조합으로 가려고 했는데, Qt Creator가 제대로 성능이 나오기 시작한 이상 굳이 이렇게 갈 필요가 없어졌습니다.

혹시나 Qt Creator로 Python 개발하시려는 분들께 도움이 되었길 바랍니다.

Saturday, March 20, 2021

Would no open source LTS for Qt shrink its user base?

It was last year(2020). Qt announced that it won't provide LTS to its open source editions.
https://www.qt.io/blog/qt-offering-changes-2020

And this year(2021), at March 4th, Qt 5.15.3, the first LTS only for commercial users is released.
https://www.qt.io/blog/commercial-lts-qt-5.15.3-released

Of course the replies for this post are under flame war from open source edition users. They say that Qt user base will shrink, the company has started the first nailing to its coffin, ...... and such. Well, the blog evokes flame war from time to time so I'm just watching it with my popcorn.......

But let's sit down and think. Would the policy of "LTS for commercial clients only" shrink the general user base for Qt? In my thought, it's absolute NO. Let me ask you one question to make it clear.

"OK. Say, let's not use Qt. Then what will we use?"

As far as I know, there's no such library which can fully replace Qt in 1 on 1 way. Some features would be able to be replaced, but Qt-only features are not replicable at all(hey, if you think you can replace Qt Quick with Electron, how would you deal with that RAM consumption?), and if you're joining some other ecosystems, chances are that the difficulty for maintenance will rise exponentially. And say, among those "alternatives," which can provide at least a good match in terms of commercial-level documentation and consistency in API structure? wxWidgets? Hey, I saw so many news to migrate from wxWidgets to Qt but not in the opposite way.

Think of it. When a new language is created, one of the external libraries bound to that language ecosystem at the first time is Qt, which shows what Qt is among developers.

Of course I fully understand the "wrath" from the open source community. I see bugs, report them, and even provide patches for them, and my contributions are applied only to commercial buyers? Yes you have your reasons. Yet...... We also have to admit that we're using commercial grade library without charge in return. And you know what? Before 2011, Qt didn't have LTS at all. (on a side note, if you distinguish open source projects to those with LTS and without one, the former will be only a handful of them).
Well, I don't say that it's great to decide not to provide LTS to open source community. I'd say that it's a typical example of monopoly. The problem is that practically there's no competition. And I don't think that the commercial market is big enough for more than two companies can coexist. Let's admit (the harsh) reality. However hard the open source community works, without good financial support(either by companies or from foundations), you need to pour the money for more than years. Do you think that there would be a company to invest more than years to build a good alternative to Qt? I don't thinks so.

Someone said that he can't upgrade the version of Qt because LTS is not provided. Well, I'd say that how would you use a library which doesn't provide LTS at all, regarding your concerns about stability?

Qt의 오픈소스 버전 LTS 제공 중지는 Qt의 사용자 기반을 줄일 것인가?

작년(2020년)이었죠. Qt가 더이상 오픈소스 버전에 LTS를 제공하지 않기로 선언했습니다.
https://www.qt.io/blog/qt-offering-changes-2020

그리고 올해(2021년) 3월 4일, 상용으로만 제공되는 첫번째 LTS인 Qt 5.15.3이 발표되었습니다.
https://www.qt.io/blog/commercial-lts-qt-5.15.3-released

들어가 보시면 아시겠지만, 댓글창은 오픈소스 사용자들의 분노(?)의 도가니탕입니다. Qt 사용 인구가 줄어들 것이라던가, 관짝에 첫 못질을 시작했다던가 하는 등등의 이야기들로 말 그대로 불타오르고 있습니다. 뭐 저 곳 블로그는 조용할만하면 어떻게든 꼭 한번씩 불타오르는 터라 그냥 그러려니 하고 있습니다만......

그런데 냉정하게 생각해봅시다. LTS를 상용 라이선스 고객에게만 제공한다는 저 정책 때문에 Qt의 사용자 수가 줄어들까요? 솔직히 말해서 전 아니라고 봅니다. 당장 이 질문 하나만 던져보면 확실해지죠.

"그래, Qt를 안 쓴다고 치자. 그럼 뭐 쓸래?"

최소한 제가 알기로는, 여기에 1:1로 매칭되는 대안을 제공할 수 있는 라이브러리같은 것은 없습니다. 일부 기능을 대체할 수는 있겠지만, Qt 고유의 기능들은 대체가 불가능할 뿐더러(혹시 Qt Quick을 Electron으로 완전히 대체할 수 있다고 주장하시는 분들, Electron이 처묵처묵하는 저 엄청난 양의 RAM은 어쩌실 생각이신가요?), 다른 생태계를 끌어들이는 순간 그 프로그램은 유지보수의 난이도가 기하급수적으로 상승하게 될 겁니다. 게다가 그 '대체재'라는 것들 중 Qt가 제공하는 상용 수준의 문서와 일관성있게 잘 다듬어진 API를 쫓아올만한 것이 뭐가 있을까요? wxWidgets? 전 wxWidgets에서 Qt로 마이그레이션한 사례는 봤어도 그 반대사례는 보지 못했습니다.

당장 새로운 언어가 나오면 GUI를 위해 가장 먼저 바인딩되는 C++ 라이브러리 중 하나가 Qt라는 것만 봐도 Qt가 개발자들 사이에서 가지는 위상이 어떤지가 보이죠.

물론 오픈소스 커뮤니티의 분노(?)가 이해가 가지 않는건 아닙니다. 난 버그 발견하고, 보고하고, 심지어는 패치까지 무료로 주는데 그걸 돈주고 파는 사람에게만 모아주겠다는건 어떻게 보면 놀부 심보처럼 보일 수 있을겁니다. 하지만 뭐...... 그 대신에 우린 높은 수준의 완성도를 가진 라이브러리를 무료로 사용하고 있잖아요. 게다가 저 LTS라는 것, 2011년 이전에는 아예 존재하지도 않기도 했고...... (여담이지만, 오픈소스 프로젝트 중 LTS를 제공하는 프로젝트와 그렇지 않은 프로젝트를 구분하면 전자는 거의 손가락으로 꼽을 수준 정도밖에 안 될 겁니다)

뭐, LTS를 오픈소스에 제공하지 않는다는게 잘 하는 짓(?)이라는 이야기는 아닙니다. 해석하기에 따라서는 독점 시장의 폐해라고도 할 수 있지요. 단지 지금으로서는 적절한 대체재가 없다는게 문제입니다. 실제로 이쪽 시장이 생각보다 좁아서 Qt급의 회사가 두 개 이상 존재할만한 크기일 것 같지도 않고요. 인정할 것은 해야죠. 오픈소스가 아무리 열심히 한다고 해도, 제대로 된 자본의 투입이 없다면 그만큼 제대로 된 무언가를 만들기가 쉽지 않습니다. 회사에서 재정 후원을 받든, 아니면 별도로 재단을 설립하든 간에 어쨌든 꾸준히 돈을 쏟아부어야 됩니다. 이미 절대강자가 있는 이 시장에 굳이 최소 몇 년 이상 돈을 꾸준히 쏟아부을 회사들이 있을지...... 솔직히 전 없을 것 같습니다.

누가 그렇게 썼더군요. 자기 오픈소스 프로젝트에 Qt LTS가 제공되지 않아서 불안해서 못쓰겠다고...... 전 거기다 대고 한마디 하고 싶습니다. 거 LTS 제공 안하는 라이브러리들은 불안해서 어떻게 쓰신데요?

Wednesday, November 18, 2020

Strangely beautiful SQL UPDATE (PostgreSQL 12)

When you need to fill data to null fields of multiple records, you had better avoid UPDATE. Rather:

  1. Prepare for a table to insert all the data to fill
  2. Use SELECT ~ OUTER JOIN to join with the original table
  3. And prepare for the "result" table to push the JOINed results via INSERT INTO.

I found out that I could finish the job in 5:35 when traditional UPDATE didn't finish in 10 minutes.

Tested under PostgreSQL 12.


이상하고 아름다운 SQL UPDATE (PostgreSQL 12)

대량의 레코드를 대상으로 빈 필드에 데이터를 추가로 넣는 작업을 할 경우, UPDATE로 각 레코드를 찾아서 갱신하는 것보다

  1.  수정할 데이터를 삽입할 테이블을 하나 더 생성해서 추가 데이터를 여기에 넣은 뒤에
  2.  SELECT ~ OUTER JOIN으로 원래 테이블과 합치고 
  3. 결과를 INSERT INTO로 별도 테이블로 밀어넣는게 훨씬 빠릅니다.

UPDATE로 10분 넘게 걸려도 안 끝나던게 이 방법을 쓰니까 5분 35초만에 끝나네요. -o-;

PostgreSQL 12로 테스트해봤습니다

Saturday, September 19, 2020

Short thoughts about PostgreSQL(+a few lines for SQLite)

For a few days ago, I started to use PostgreSQL. Current development is not using database as it becomes I/O bottleneck, so I merely write down everything from RAM to disk at once(and additionally it is compressed in LZ4 to shrink write time). The problem was, that RAM usage skyrocketed as target data becomes TBs. Just guess what you feel when you encounter out of memory after 10 minute operation. What's worse, since I was working on portable server, the total amount of RAM was limited to certain degrees, not like rack-type servers.

So, I changed the mind model - use DB like as something like swap file! Currently the process is processing all the data on robin hood hash, but if we can control them under a database table and remove that table after use, we can save RAM dramatically(well, at least out of memory won't be shown if we limit working memory for DB).

At first, I tried SQLite. It consumes so low on RAM so that even Android and iOS can use, and before that I developed a class optimized for bulk insert with the engine. However, soon I found that it consumes practically infinite time when the query is even slightly complicated. When I tried an inner join query with two tables with 7 million records each, I gave up after 30 minutes. And it couldn't process in parallel since the engine is working only on single thread.

Later, I found out that SQLite uses only nested loop on table joins. If we're working on previous case(two tables with 7 million records each), we need to loop for 49 trillion times. And it should work on single thread. Oh God.

As I was cornered and forced to use "ordinary" database, my choice was MySQL, MariaDB, and PostgreSQL. MySQL was dropped at early stage as no tweak and tuning seems to have worked as I intended, so my choice became more limited. And I chose PostgreSQL for its a few exceptional features:

  1. It's not snail-slow as people say. Instead, if you tweak just few, it "flashes." No, I can't agree with the words "it's slower than MySQL or MariaDB." When you're working hard to tweak MySQL/MariaDB to maximize its performance with your complicated tweak but if you don't do same amount of efforts and try PostgreSQL just out-of-box, well, it's not fair. Isn't it?
  2. Parallel query processing! If you send a query the scheduler "smartly" judges and multi processing is done as needed. For my inner join of two tables with 7 million records, it consumed 3 cores and gave result in 1 minute 30 seconds.
  3. It's simply reliable in any bad condition. After stress test, PosgreSQL survived and gave result when MariaDB service was restarted

Currently I'm using it as if it's some kind of hashmap. Well, maybe that's because I previously worked with them. Thinking that the basis of database indexing is hashmap, it may be one of the best practice for any SQL based database. Additionally, my coding became simplified since database does  most of the things automatically......

Now I agree with the slogan, The World's Most Advanced Open Source Relational Database. Keep up the good work, PostgreSQL Global Development Group!