-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Better multithreading code #1394
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Looks like Travis infrastructure is having issues again: 😦
|
I had to include |
Thanks! For some reason I removed that include. It's fixed now. Travis decided to re-run the build, too, and complained about the same missing include. |
b0066eb
to
ff6545f
Compare
Here's a list of the TODOs mentioned in the patch by Michael Krause:
|
ff6545f
to
35bcad0
Compare
Yay, Travis is finally reporting a success 🎆 So that's the first major step done towards merging this 😄 |
Not sure it's relevant, but these warnings show up when compiling this branch on OSX:
|
I've tried out the one-off OSX build. I loaded a large data set (~500K lines). I saw the significant improvements in responsiveness in switching to the "Browse Data" tab and improvements when I scrolled and jumped to an arbitrary place in the listings. I didn't see any weirdness. |
That bodes well. Thanks for helping @mkweskin. 😄 |
There is a problem in this branch with the filters. Every keystroke in the filter box makes the box loose the focus, which is annoying for the user. I've looked for something related to focus switch in the changes without success. I suppose something is triggered that ends in this focus loss. |
@justinclift Those warning should be fixed with yesterday's commit. Nothing serious there but good to fix them anyway. @mgrojo Good point. Turns out I only ever tested the filters in this branch with one-character search strings 😉 I believe the commit I have just pushed is the proper way to fix this and it definitely has less side effects than the other ideas I had for this. Still worth testing it though. |
@MKleusberg Thanks. I'll check in a bit and see if there were any others too. 😄 |
@MKleusberg The problem with the filters is solved now 👍 I've been testing it with a big database (an import of National_Statistics_Postcode_Lookup_UK.csv). It works really good. Sometimes I miss a bit of feedback about being working on it for the operations that take a bit of time, like the filters (only that "determining row count...", which can isn't very noticeable) or the plot. |
I've remembered #1373 and, willing see how it behaves in this branch and fearing that it takes all my RAM, I've selected the entire table of the big postcode DB using the upper left corner. It indeed seems to work as expected because it was blocked for a long time. I left it alone and when I came back it had finished without message in standard output nor /var/log files. In the master branch it can select the visible rows, but it cannot copy and paste them to another application (it also gets blocked). I guess this branch solves the partial selection problem described in #1373, but it leads to a new question. Should we let the user select an entire big table without any warning? |
Just tried out this new branch with the UK postcode database too. Wow. This is a lot faster and more usable. Well done guys. 😄
I guess this is one of those things where we should do some measurements on the PC we have, to work out what size of data selection makes things slow. Maybe we should add some debug logging (in a branch), to output stats to (say) a dialog or log file, and we can collect the stats info in an issue. Once we have some data to work with, we could figure out where the warning (or whatever) thresholds are. |
Hmmm, the improvement when working with larger data sets is pretty huge. I'm making new once-off builds for Win and OSX now, and we can point people at them via Twitter and some of the existing issues here. That should get people testing things. 😄 |
@MKleusberg Found something interesting when compiling this branch on Windows just now. It was erroring out with something along the lines of not being able to find Did a quick bit of poking around, and it looks like the new Testing on CentOS 7 x64 just now... that compiles fine either way. Doesn't seem sensitive to |
Just had another thought for the "should we let users select a big table without warning?" thing. Are we able to detect the start of the selection event, and if it runs for longer than (say) 3 seconds we pop up a warning dialog of some sort? |
@justinclift I was taking a look at old issues. Should we also notify the reporters of #761 and #503?
I don't know if it's feasible, but it would be a solution. |
Thanks @mgrojo. #503 looks like a good candidate. I'll ping the people in that now. #761 is performance related, but in a different area to this so we can skip contacting the people in that for this. We do need to verify if the fix already done (and merged) for #761 has completely solved that issue. Personally, I can't be bothered testing that one just now. 😉 |
@MKleusberg Just a minor reminder, we'll still need to do something about that |
@justinclift Oh yeah, completely forgot about that. I think we can just get rid of it entirely. But let's see what Travis says about that 😄 |
Damn. Looks like we'll be needing some
|
984f0a0
to
d585024
Compare
Ok, now it builds 😄 @justinclift Can you give it a try on Windows to check if it works there too? |
d585024
to
2e25b3f
Compare
This was done by Michael Krause. https://lists.sqlitebrowser.org/pipermail/db4s-dev/2018-February/000305.html In this commit I only fixed two compiler warnings, some whitespace issues and removed some debug messages.
Make strings translatable, remove some more debug code, fix tests, reduce size of patch slightly, remove weird tooltip, don't crash when closing database, simplify code, fix filters, don't link agains pthread on Windows.
56f92f9
to
b2b2fbd
Compare
Improve the enabling and disabling code for the insert and delete record buttons in the Browse Data tab. With this the buttons should be enabled if and only if they can actually be used. The commit also makes the code easier to read because the final state of the buttons don't depend on the call order of the involved functions anymore. Instead there is only one function now which enables and disables them. This also fixes one TODO in the multithreading patch.
I have rewritten the commit series and rebased this branch to master. Also I have fixed the first TODO from the list above. |
Whoops, was doing stuff offline so didn't see this. I'll try it on windows in a bit. 😄 |
It's compiling now. Some more warnings we might want to clean up too:
The build itself succeeded and seems to run ok, which is the important thing. 😄 |
The warnings mostly seem to be unrelated to the multithreading patch. So I'll probably ignore them for now to not delay this PR. But feel free to open an issue for them - always good to have no warnings on all compilers 😄 |
The multithreading patch didn't properly load all data into the cache when this was necessary. It would only do so if the chunk size was sufficiently high. This is fixed in this commit. Show a progress dialog while loading all data which can be cancelled by the user. When cancelling the loading of all data in those cases which require all data to be loaded, stop whatever process needs the data too.
... and the second TODO should be fixed now 😄 Since the third one (In RowCache.h: introduce maximum segment size?) is an open question and the forth one (In SqliteTableModel::handleFinishedFetch(): optimize) is no blocker, I will merge this PR in the evening - that is, if nobody finds any other issues until then 😉 |
Sounds good to me. 😄 |
OK, going to merge this then. I'm trying to not delay this PR any further (now that the most prominent remaining problems are fixed) because I think in the nightly builds the code should get a decent amount of testing. And it can't hurt to test this a bit more before the release 😄 So if anybody notices anything (really anything; e.g. the last commit also fixed some problems which were introduced in the Edit Table dialog) please open an issue. |
Almost forgot about this. #1423 is the new issue for it, so we don't actually forget. 😄 |
This is the patch which Michael Krause posted here. I have changed his code to apply cleanly on the current master branch, fixed some compiler warnings and some whitespace errors. No major changes there - that's the first commit. Then I did some extra changes which I thought made sense and added them as extra commits.
It should compile and it should run, so please give it a test if you can. There are still some "TODO" comments in the code and they definitely need to be addressed but the new code is a huge improvement in my opinion. But I haven't yet tested this thoroughly.