Some time ago, I noticed that a unit test was quite slow, using 100% CPU for a number of seconds at one point in the test.

I used perf and KDAB’s Hotspot to record and examine where the CPU cycles were spent in that unit test, and I quickly noticed that a lot of time was spent in QFileSystemEntry::fileName(), an internal method in Qt that’s called when listing directories with QDir.

Here’s what zooming into that method with Hotspot showed:

We can see that QFileSystemEntry::fileName() calls QString::lastIndexOf(), which calls data() on the string, i.e. detach(), leading to an expensive deep copy! Surely that’s not supposed to happen from a const method. Looking at the Qt code revealed that lastIndexOf() calls a template method which calls .data() on the string-like template type (which is in this case a QString but can also be QStringView or QLatin1String, and those don’t have a constData() method). The author of that method in fact never intended for it to be instantiated with a QString type besides QStringView, but that’s exactly what happened, accidentally. The fix was, therefore, to wrap the QString in a QStringView, whose data() method does not detach.

After making the change, the expensive detach() disappeared:

Don’t be fooled by the fact that the rectangle for QFileSystemEntry::fileName is just as wide as before. I selected it in Hotspot, so it always takes 100% of the width. However it’s 100% of a much smaller amount now.

I submitted the fix for inclusion into Qt and it got merged into Qt 5.14.1 and following versions. You can see the patch in the Qt merge request.

By the way, when I give trainings about profiling of C++ applications, I always insist that profiling should be done on an optimized build, never on a non-optimized (“debug”) build. This is so we don’t do the job of the compiler optimizer ourselves. But this is one case where even profiling a debug build showed very interesting results, and the fix had an impact on release builds as well. That’s because, in this case, the compiler cannot optimize away the deep string copy triggered by the call to data(), so the bug did exist in optimized builds too.

In conclusion, if something is slow, fire up Hotspot, record the program (ideally a unit test, but the full program is also a possibility), switch to the flamegraph, and hopefully the reason for the slowness will be very visible.

Happy profiling!

The post Hotspot: How const Can Improve Performance appeared first on KDAB.

Tuesday, 27 July 2021. Today KDE releases a bugfix update to KDE Plasma 5, versioned 5.22.4.

Plasma 5.22 was released in June 2021 with many feature refinements and new modules to complete the desktop experience.

This release adds three weeks' worth of new translations and fixes from KDE's contributors. The bugfixes are typically small but important and include:

• Discover: Address the keyboard shortcut tooltip. Commit. Fixes bug #438916
• Sort Unsplash POTD image categories alphabetically. Commit. Fixes bug #422971
• Info Center: Unbreak about CPU value when solid is missing a product string. Commit. Fixes bug #439464

GSoC 2021 KMyMoney - Post First Evals to Week 7

The plan for the post first evals week was to complete the following tasks:

• Make changes as suggested by mentors on my last work.
• Modify the AlkOnlineQuoteSource constructor for new members (m_idSelector and m_idNumber)
• Write unit tests for the added members in the AlkOnlineQuoteSource.

I modified the code as suggested by my mentors that were related to coding conventions(according to C++, Qt and KDE).

After adding the new members to the AlkOnlineQuoteSource constructor. I jumped into writing the unit tests. I realized that I haven’t added the new members in the function signature. After adding that, I build the files to check what all things break related to the constructor’s usage. They were :

• defaultQuoteSources() - The function having default quote sources. I modified those according to the new signature with quotes data from webpricequote.
  I proceeded to work on tests then and modified the test functions according to the new signature. I ran all the tests only to realize later that alkonlinequotesourcetest fails. It was due to the undeclared IdSelector variable. After fixing(assigning a default type) it was very relaxing to see all tests pass.

My work can be found here : Alkimia and KMyMoney.

Learnings -

I got to know more about the importance of coding conventions and writing tests.

What’s next -

This week will revolve around implementing the libalkimia changes in kmymoney. I am also looking at this https://bugs.kde.org/show_bug.cgi?id=439411 as suggested by Ralf.
If anyone wants to suggest something or have a discussion please reach out to me on suraj[dot]mahto49[at]gmail[dot]com or @suraj_sloth:kde.org in matrix.

Setup on Windows

setting up mingw on windows is PITA, at first since i am not used to backslash for filepaths, it load the gdb printers, i then realised that it does not come with python enabled. Downloaded a new one it does not come with python3 instead it is python 2.7.

I could not find any mingw that is built with python3 on windows, if you do send me a link here.

New Printers

• QFile

  this private class has the following structure

  type = class QFilePrivate : public QFileDevicePrivate {
  protected:
  QString fileName;
  
  QFilePrivate(void);
  

  it inherits from a QFiledeviceprivate, but the size of the qfiledeviceprivate is not consistent across operating system, architectures and qt5 versions.I got the list of offset from the qtcreator types this problem exists for also qprocess (not fully implemented as of now) and for others as i may not be able to get it size for all operating systems, architectures and qt5 versions.

  relevant commit

• QDBusMessagePrinter

• QUUidPrinter from here

Fixes and Tests

• Added QByteArrayPrinterTest
• Fix QFileInfoPrinter causing segfaults when calling a method that does not exist commit
• The tests only runs when CMake builds successfully

Here is a link to the repo

Hi reader! It's been some time since I have posted a blog on my GSoC project. I am writing this blog to keep you updated with the development of Krita. To avoid duplicating code I have gone through relevant part of existing code in Krita (again). I must say it always amazes me as the … Continue reading GSoC’21: Week 4-7 with Krita →

Tok now has TWO new completely revamped upload dialogues: one for desktop, and one for mobile. Despite how much of the app is spent using stuff that isn't the upload dialogues, the upload dialogues took a LOT of time and work to get implemented correctly.

The mobile dialogue makes it convenient to browse through your most recent photos, videos, music, and files to share them with your friends.

On desktop, the upload dialogue now offers a preview of your file, and for images, the option to compress it.

Sending State

The sending state of outgoing messages is now displayed with a little icon by the timestamp.

Adjusted Chat List Look

The look of the chat list has been slightly adjusted, to make it look more like other KDE apps. More information is shown, such as the sending status of outgoing messages and the timestamp of the latest message.

Improved Pasting

Tok now has improved pasting capabilities, able to paste from apps that put images on the clipboard directly like Firefox and Spectacle now.

Obtaining Tok

Tok can be built from source from https://invent.kde.org/network/tok.

There's a Telegram room for Tok available at https://t.me/kdetok, where you can come on and chat about anything Tok related, such as asking questions on using or building Tok.

Contributing

Interested in contributing? Come on by the dev chat and say hello!

Tags: #libre

Kubuntu Groovy Gorilla was released on October 22nd, 2020 with 9 months support.

As of July 22nd, 2021, 20.10 reached ‘end of life’.

No more package updates will be accepted to 20.10, and it will be archived to old-releases.ubuntu.com in the coming weeks.

The official end of life announcement for Ubuntu as a whole can be found here [1].

Kubuntu 20.04 Focal Fossa and 21.04 Hirsute Hippo continue to be supported.

Users of 20.10 can follow the Kubuntu 20.10 to 21.04 Upgrade [2] instructions.

Should for some reason your upgrade be delayed, and you find that the 20.10 repositories have been archived to old-releases.ubuntu.com, instructions to perform a EOL Upgrade can be found on the Ubuntu wiki [3].

Thank you for using Kubuntu 20.10 Groovy Gorilla.

The Kubuntu team.

[1] – https://lists.ubuntu.com/archives/ubuntu-announce/2021-July/000270.html
[2] – https://help.ubuntu.com/community/HirsuteUpgrades/Kubuntu
[3] – https://help.ubuntu.com/community/EOLUpgrades

Last week brought a significant new addition: the schedule view. It, and all of the other features explored in last week’s post, have been added over the course of this week and are now part of the master branch of Kalendar!

1. !8: Improved event info drawer, event collection editing, attachments
2. !9: Add undo/redo functionality
3. !10: Add a schedule view to Kalendar

This week brings a number of smaller visual tweaks and a significant new feature that has involved a lot of wrangling inside Kalendar’s guts. Let’s go through ’em!

Making the incidence editor prettier

!11: Improve appearance of incidence editor

The incidence editor’s has been modified to make it nicer to look at and easier to differentiate between its different sections. The description textarea has been moved to the top, and separators have been added between each of the model-driven sections (attendees, attachments, reminders, and recurrence exceptions).

Additionally, these model-driven sections have been changed to use much more visually attractive Kirigami components.

Tweaks to the calendar views

!10: Add a schedule view to Kalendar (and tweak the month view)

Kalendar’s views have seen some small changes. First, the schedule view: on desktop, the padding on the cards has been reduced in order to present more incidences at once, since on desktop the cursor allows you to click on smaller cards just as precisely.

Additionally, both the schedule and the month view now let you double-click on a date in order to instantly open the event addition window set to the date you double-clicked on. Right-clicking opens a context menu that lets you specify what kind of incidence you’d like to add.

New incidence types

!12: Add support for more incidence types

That’s right! A lot of work has gone into Kalendar this week in order to let you view, edit, and add different types of incidences. Now, you can add todos in addition to events to your calendars. This has meant significant changes under the hood, which should make work to add support for additional types of incidences much more straightforward.

Including new types of incidences has also meant some changes to the UIs of different parts of the application. Event addition buttons are now replaced with menus that let you select the type of incidence you want to add, for example. Both the month and schedule views now show what type of incidence something is alongside its name. The layout and contents of the incidence editor also change depending on what sort of incidence you are adding or modifying. In the case of todos, you can also mark them as complete or incomplete from the incidence information drawer.

This merge request is big, so it is still under review (sorry!) but it should land over the next few days.

Coming up next

Up next will be to finish tailoring the different aspects of Kalendar to accommodate new incidence types. This will include changes to the incidence editor to include support for additional and specific features of todos. Journals will also be added in the next few days.

Also coming up is the addition of a view focused on todos — but more on that when it’s ready.

Is there anything you’d like to see added to Kalendar? Get in touch! I’m @clau-cambra:kde.org on Matrix.

This is part three of a series of posts describing a potential new API for dealing with countries, country subdivisions and timezones in KI18n, following the previous one country to timezone mapping, covering how we can query the timezone and country or country subdivision information by geographic coordinates.

API

The API for this is fairly straightforward, pass a geographic coordinate in, and get the respective feature at that location back:

• KCountry::fromLocation(float latitude, float longitude)
• KCountrySubdivision::fromLocation(float latitude, float longitude)
• KTimeZone::fromLocation(float latitude, float longitude)

This doesn’t need to overly precise coordinates, even GeoIP-based positions with an accuracy of a few kilometers provides useful results in most areas.

Data Sources

The data sources for this are the same we already used in the last post:

• The IANA timezone boundaries polygons.
• The countries and country subdivisions boundaries polygons.

Both are based on OSM data.

Compact Storage and Indexing

The source data however is huge and slow to process, we need to convert that into a compact form allowing efficient storage. For this we reuse prior work from KItinerary which contains a z-order curve based coordinate to timezone index.

There’s a few improvements and extensions over the original code though. Most notably we can now represent multiple features per location, while using the fact that there is only a small set of feature combinations actually occurring. This allows us to look up not only timezones but also the country or the country subdivision by location, without significantly increasing the needed storage size.

The QGIS Python script doing the processing also got optimized a lot, the original version from KItinerary needed about eight hours, the new one only needs about 15 minutes while producing a more detailed result. This makes it much more feasible to experiment with tweaking the various parameters to get to optimal results.

Choosing Parameters and Conflict Resolution

Obviously we can’t just magically reduce the hundreds of megabytes of source data by two orders of magnitudes without trading in spatial resolution, how much depends on the parameters of the index generation script.

There’s three values to keep an eye on:

• For how much of the earth’s surface do we return a result?
• For how much of the earth’s surface do we return the wrong result?
• The size of the index data.

To understand how we can influence those it’s useful to have a quick look at what the index generation does conceptually.

• Split the earth’s surface in rectangular tiles (currently: 2¹¹ x 2¹¹). Cut off uninhabited polar regions to have more tiles for inhabited areas (currently: 80°N and 60°S). For our current parameters that results in tiles roughly 10x20 km at the equator, and increasingly smaller towards the poles. This controls how much surface area we can cover, and how large features have to be in order to be visible at all.
• For each tile, check which of the features in that tile actually conflict. For example a tile overlapping the French/German border would see two timezones Europe/Berlin and Europe/Paris. Those two are (at least for the present and near future) equivalent, so we just pick one of those and don’t have an actual conflict. For the country we obviously can’t do that, so there we wont be able to return a result.
• For each feature conflict, discard those features that only cover a small fraction of the tile (currently: 2%). This trades correctness within a few hundred meters of a border for a larger coverage area.

With the above mentioned parameters, we get to an index size of about 950kB, and cover 99% of the non-polar regions for timezones and countries, as well as 98% for (first level) country subdivisions, and we shouldn’t get wrong results when being away at least 300 meters from a border.

This is a decent trade-off for many use-cases, further reducing the tile size results in a rapidly growing index size for a decreasing win in precision.

There are ways to break this of course, land-locked and shaped against the tile orientation mini-countries such as Lichtenstein can fall through the cracks entirely, even more so their subdivisions. Similarly, very fine-grained country subdivisions can also be missed, but in those locations we tend to at least get a correct country information.

Outlook

There’s two more remaining aspects to be sorted out now:

• Human readable and translated timezones names. Unlike with countries there is no canonical form for this, applications tend to use different approaches to represent timezones. It’s still unclear which building blocks for this can be offered by KI18n.
• Looking up the language of a country or country subdivision, as well as human readable and translated language names. This needs a bit more thought as well, as code referring to languages often rather expects locales (area and/or script variants used in a specific area), as well as the available translation catalogs on the system.

Feedback for all this is very welcome, on the implementation but also regarding use-cases and requirements you have in your application. Check the corresponding Phabricator task and the Gitlab branch for this, or find me in the #kde-devel channel on Matrix, the weekly KF6 meetings (Monday 15:00 UTC) or the kde-frameworks-devel mailing list.