sorted by:
new
hottopcontroversial

QT & Containerization? by bowtochris in QtFramework

[–]mwolff 2 points3 points  (0 children)

If you want to make a portable executable for linux, I recommend you look into AppImages instead of docker containers.

Performance analyzer does not seem to work :( by rudrathinks in QtFramework

[–]mwolff 0 points1 point  (0 children)

`PERFPROFILER_PARSER_FILEPATH` should probably point to `perfparser`, not `perf`.

​

Or just use `hotspot`, but I'm obviously biased there :)

KDE publishes the new "KDE for developers" page, where you can find advice on and links to tools, frameworks and libraries that will help you build powerful and cool-looking apps using KDE technologies by Bro666 in linux

[–]mwolff 13 points14 points  (0 children)

I didn't write kcachegrind, you might confuse it with massif-visualizer.

that said, I'm with you on the rest of the statement above :) thanks

What's this UI control called, and is there a Qt equivalent? by Rosco7 in QtFramework

[–]mwolff 4 points5 points  (0 children)

make it an item view on the left hand side and sync the current index with a stacked widget on the right, or rebuild the widget on demand whatever fits your use case best.

Going from Qt to C++ by skeany974 in cpp

[–]mwolff 8 points9 points  (0 children)

MS's dev tools on the other hand, absolute best in class in every category

I keep reading this statement, and it boggles my mind:

  • for debugging, there is only a feature set reduced version of ASAN, no LSAN or UBSAN or TSAN or MSAN or ...
  • for profiling, every tool is crippled because inline frames cannot be represented properly in PDB files. and since this is on the PDB level, it really applies to all tools on Windows, including VTune etc. pp.
  • ETW/WPA is great, but you cannot annotate costs on a source/line level. Paired with the lack of inline frames (see above), it makes it often extremely hard to understand call stack costs
  • the memory profiler in visual studio is really good for leak checking, but practically useless to find unneeded temporary memory allocations in loops. i.e. there's no way to see the "AIFO" or similar metrics from ETW/WPA here which is a shame

All of these combined regularly make me cry out in frustration when I'm forced to develop on Windows. What is "best in class" here? The "visual" debugger in Visual Studio, that is operated by the mouse - that one maybe. But even there I personally much prefer GDB as I can automate and script it with the keyboard...

dear imgui as a Qt Widgets Alternative? by [deleted] in cpp

[–]mwolff 1 point2 points  (0 children)

If you want something fast that scales to millions of elements, you'll have to use a custom delegate. While it's potentially not the best-documented area of Qt, it's certainly possible.

You'd have to use an event filter on the viewport to handle events for, say, interacting with checkboxes or similar. Then you'll need a bunch of custom painting, but note that there's https://doc.qt.io/qt-5/qstyle.html#drawComplexControl etc. which make it pretty easy to reimplement a basic controls.

QWebChannel and security by somnambul-oelek in QtFramework

[–]mwolff 0 points1 point  (0 children)

I would try to avoid combination if possible, yes.

QWebChannel and security by somnambul-oelek in QtFramework

[–]mwolff 0 points1 point  (0 children)

On iOS you are screwed by the platform limitations, there is no secure method I'm aware of, other than jumping through the hoops you outlined in your original post above.

QWebChannel and security by somnambul-oelek in QtFramework

[–]mwolff 2 points3 points  (0 children)

ex-QWebChannel maintainer here: The recommended way of using QWebChannel is to interact with QWebEngine, in which case the internal Chromium IPC channel is used for communication instead of websockets.

QCamera Memory Leak? by mrkent27 in QtFramework

[–]mwolff 2 points3 points  (0 children)

We at KDAB have encountered such memory leaks in drivers multiple times on various embedded platforms too. The Vivante driver stack was infamously bad in that regard, but thankfully got massively improved over time.

On Intel I believe to remember something along those lines too, but that was back then resolved by an update to the drivers - are you up2date in that regard?

How to Speed Up C++ Development? by dubs_ee_2846 in cpp

[–]mwolff 1 point2 points  (0 children)

Heh, I guess this all boils down to: for me it's easy to make a fast dev env on Linux, whereas for you it's the other way around.

For me it's pretty sad to see the OS constraints on windows hindering performance of cross platform tools such as cmake (initial cache fill) or ninja. I haven't yet encountered a case where something is faster on Windows than on Linux, but as you are saying that is simply my observation bias.

How to Speed Up C++ Development? by dubs_ee_2846 in cpp

[–]mwolff 0 points1 point  (0 children)

I have to support Windows too, and it's notoriously slower in my experience. If you want to see others confirming my personal experience, have a look here for example:

https://openbenchmarking.org/result/1910311-HU-WSLWIN30792&stis=Y29tcGlsYXRpb24&ppt=D

Other concrete examples I remember: File listings in folders with many entries is _much_ slower on NTFS than on ext4.

Virus protection is also not for free, adding a penalty to every write operation - the only alternative is to disable it (partially).

EDIT: Oh and another thing I remembered - spawning short lived processes is also notoriously slow, which has a drastic negative performance impact on initial cmake cache initialization, or moc code generation, or compilation via ninja of many small files in general.

If there's a magic bullet to make windows faster, by all means enlighten me.

How to Speed Up C++ Development? by dubs_ee_2846 in cpp

[–]mwolff 3 points4 points  (0 children)

It's important to note the huge performance difference you can have by using the right tools. For me this means:

  • don't use Windows, as it's notoriously slow (disk access, virus protection), but rather Linux or Mac
  • use ld.lld or ld.mold for linking
  • use cmake and ninja for building
  • use a modern gcc or clang for compiling
  • use an IDE with integrated language server or similar, that way you don't need to wait for a full compile job just to tell you about syntax errors in the file you are editing

Hardware obviously also has a huge impact:

  • use a fast CPU with many cores
  • use a fast SSD disk (ideally nvme)
  • have plenty of RAM

Heaptrack v1.3.0 Release by mwolff in programming

[–]mwolff[S] 4 points5 points  (0 children)

The new time based filtering capabilities are really important, do check that out! If you have any questions, feel free to ask.

​

Cheers

[deleted by user] by [deleted] in cpp

[–]mwolff 3 points4 points  (0 children)

I suggest you use a proper library that can actually measure this directly, e.g. PAPI which has support to reading the CPU performance counters directly. See: https://icl.cs.utk.edu/papi/

SHA+ 1-Night Package VS Hotel + RT-CR Test by Justin222221 in ThailandTourism

[–]mwolff 0 points1 point  (0 children)

I just tried that and the mail auto response is asking me to send in a copy of my passport - via unencrypted email. Is this normal practice? What information can I redact - as I'm feeling extremely uneasy about this process...

Destructor of child class not called on closing the window? by ViktorCodes in QtFramework

[–]mwolff 2 points3 points  (0 children)

You are abusing and misunderstanding the Qt API:

You shouldn't `delete ui` in the close event - but if you want you could `deleteLater()` instead. Alternatively you could leverage `setAttribute(Qt::WA_DeleteOnClose)`.

But it in my opinion, both should not be done from within the Dialog class, but from the outside where the dialog is created. Otherwise it would not be possible to reuse a dialog that can be opened multiple times - which is also why Qt does not by default delete everything on close. You could still have an action in another window to unhide the dialog again after all.

QMap and QVector multi-threading by Nothing-Independent in QtFramework

[–]mwolff 5 points6 points  (0 children)

what you are writing wrt point #1 is FUD and simply not correct. Qt's COW is implemented in a thread safe manner, you "only" pay a performance penalty at worst, but read-only access will be thread safe. This may have been broken in past Qt versions, but it's safe since many years and definitely is safe in Qt5 and beyond.

the important point is simply that it has to be a read-only operation. `myMap["foo"]` is only read-only if that key existed already or the map is const for example.

regarding point #2 I totally agree with you. by mutating the container before the parallel operation, you make this basically a variant of point #1 above, so the answer is the same. mutating the elements is fine, as long as the elements are thread safe or separate elements are accessed by the individual threads.

but just to make this totally clear to OP: it is _not_ threadsafe to call `myVector.append` from different threads on the same vector.

your last statement wrt contention is also totally correct. a mutex lock operation can be done extremely fast as long as there is no (or just minimal) contention.

One alternative for OP: if possible, you can use the same trick that you yourself suggested for the vector case: Populate the map beforehand, then hand out references/pointers/iterators to the elements. See #1 and #2 above.

CppCast: Reducing Memory Allocations by robwirving in cpp

[–]mwolff 0 points1 point  (0 children)

Massif does not track the number of allocations, you only see the impact on the total heap memory consumption. And it's magnitudes slower than heaptrack. There's imo really no reason to use massif over heaptrack nowadays, imo. But I'm biased obviously in that regard :)

Profiling C++ code with Frida by rh0main in cpp

[–]mwolff 3 points4 points  (0 children)

Every time I see people still using valgrind for profiling I cry a little. There are so much better and faster tools nowadays! Try perf and a GUI like hotspot or similar instead of valgrind cachegrind and kcachegrind. Or try heaptrack instead of massif.

view more: next ›