View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000455 | Twitter Delitter | Backend / Core | public | 2020-02-07 16:04 | 2020-02-17 11:17 |
Reporter | BootBlock | Assigned To | BootBlock | ||
Priority | urgent | Severity | minor | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Product Version | 1.33 | ||||
Target Version | 1.34 | Fixed in Version | 1.34 | ||
Summary | 0000455: Re-serialisation of each tweet deletion | ||||
Description |
Thanks to Danny T. for reporting! | ||||
Additional Information | This happened in a prior version of TD but was fixed, so I'm wondering if it's a regression. It's a performance killer and for a stupid reason, too. | ||||
Tags | I/O | ||||
|
The re-serialisation madness was a dumb oversight when it came to purging tweets; I so rarely use Purge that I didn't actually test it and even forgot what its purpose was. Next up: seeing why re-serialisation happens when deleting tweets as that was the issue that was fixed before. |
|
My understanding was that purging was "marking the tweet as deleted (or removing it) from the main tweet list". Thus, it seems to also happen automatically at the end of a delete operation (to remove the deleted tweets from the list - the only reason I was doing it manually this time was because I had End Task'd, and ended up with deleted tweets still in my list). So I think these are just one issue - that purging tweets is re-saving the full tweet db (Tweets.jso) in between each tweet. Persisting the file once after all purging (or at least after batches) probably fixes both issues. |
|
There doesn't seem to be anywhere where the Archive or Queue collections are being serialised (other than the initial Purge fix above), so yeah it looks like it was related to just Purging. I don't like the delay when adding 15,000+ tweets to the Deletion Queue as that seems related to the ObjectListView - I'll need to double-check that I'm freezing the drawing as my first guess would be it's related to that. In fact, the Deletion Queue ListView kinda runs like arse; again, ObjectListView... |
|
Alright, huge speed-up when adding/removing tweets to/from the Deletion Queue. Still not quite where I want it, though... |
|
Will Close this task when the fix has been confirmed. |
|
Is it available for testing? |
|
I'll do a build you can test once the Ebook stuff is done. Even though the tweet scoring UI is mostly done, I'll postpone the scoring stuff until 1.35 just in case loads of stuff explodes at once... |
|
No need to rush a build, I just wasn't sure if the comment meant I could test it already. Happy to test it whenever it's ready :-) |
|
TD looks like it's working alright, so I'll do a build in the morning (10th) as I'm already falling asleep from all the beef cakin' I've been doing. |
|
My time machine is broken, so I might have to wait until after the morning of the 11th to test :-) |
|
Is there anything you haven't broken? Alright, make it the 11th. And... here you go! How'd ya do links in this, again? There's stuff that doesn't work (namely the Tweet Score stuff) but the serialisation and I/O stuff are fully done - I think. Bit of a rush this morning, and the mutex/reset events haven't yet been extensively tested but seemed to work. Make sure to use your already installed version and do a Download: -- removed; download the latest public version for these changes --I've posted it here in case anyone else wants to test it; note that a valid license will need to be installed to test the online stuff, as usual. |
|
Works much better now thanks (the remaining hang is the one you mention above). Thanks! |
|
Woo, will mark as Closed soon - ta! |
Date Modified | Username | Field | Change |
---|---|---|---|
2020-02-07 16:04 | BootBlock | New Issue | |
2020-02-07 16:04 | BootBlock | Assigned To | => BootBlock |
2020-02-07 16:04 | BootBlock | Tag Attached: I/O | |
2020-02-07 16:04 | BootBlock | Status | new => assigned |
2020-02-07 16:15 | BootBlock | Note Added: 0000181 | |
2020-02-07 16:26 | DanTup | Note Added: 0000183 | |
2020-02-07 17:09 | BootBlock | Relationship added | related to 0000456 |
2020-02-08 22:13 | BootBlock | Note Added: 0000188 | |
2020-02-08 22:13 | BootBlock | Description Updated | |
2020-02-08 22:13 | BootBlock | Description Updated | |
2020-02-08 22:40 | BootBlock | Note Added: 0000189 | |
2020-02-09 09:57 | BootBlock | Status | assigned => resolved |
2020-02-09 09:57 | BootBlock | Resolution | open => fixed |
2020-02-09 09:57 | BootBlock | Fixed in Version | => 1.34 |
2020-02-09 09:57 | BootBlock | Note Added: 0000191 | |
2020-02-10 09:00 | DanTup | Note Added: 0000195 | |
2020-02-10 13:47 | BootBlock | Note Added: 0000196 | |
2020-02-10 14:23 | DanTup | Note Added: 0000197 | |
2020-02-10 18:24 | BootBlock | Note Added: 0000198 | |
2020-02-10 20:05 | DanTup | Note Added: 0000199 | |
2020-02-11 08:21 | BootBlock | Note Added: 0000200 | |
2020-02-11 08:22 | BootBlock | Note Edited: 0000200 | |
2020-02-11 08:22 | BootBlock | Note Edited: 0000200 | |
2020-02-11 08:23 | BootBlock | Note Edited: 0000200 | |
2020-02-12 14:18 | DanTup | Note Added: 0000204 | |
2020-02-12 15:42 | BootBlock | Note Added: 0000209 | |
2020-02-17 11:17 | BootBlock | Note Edited: 0000200 | |
2020-02-17 11:17 | BootBlock | Status | resolved => closed |