Zandronum Chat @
Get the latest version: 3.0
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003638Doomseeker[All Projects] Suggestionpublic2019-04-30 20:392019-07-30 10:13
ReporterPol M 
Assigned ToPol M 
PlatformLinuxOSArchOS Versionx86-64
Product Version1.2 
Target Version1.3Fixed in Version1.3 
Summary0003638: Cache files checked on PathFinder::findFile to allow for a more efficient multi-file search
DescriptionCaching the files will allow for a faster lookup in multi file searches. That is specially useful to speed up the PWAD tooltip.
Additional InformationThis also means that the PathFinder must not be destroyed in the tooltip lookup.
Attached Files

- Relationships
child of 0003625closedPol M Servers with lots of (big) WADs may take a long time to display the WADs column tooltip on server browser 

-  Notes
User avatar (0020579)
WubTheCaptain (developer)
2019-04-30 20:46

Quote from Pol M
Originally with this ticket I played around with the idea of caching the files of directories already explored, allowing us to cut a lot of time in certain cases. Maybe I'll explore the concept further.

I kind of prefer it being real-time as it is right now. I've found it useful on multiple occassions while moving files, no need to restart Doomseeker to see if the file exists at that path. The alternative offered is to disable telling where the paths are located, in settings.
User avatar (0020583)
Pol M (developer)
2019-04-30 21:51

No, I'm not saying to cache all the wads at load time. I'm talking about Caching the search results of one item in the tooltip to be able to reuse them in the next item of the tooltip. This reduces access to the hard drive significantly at the expense of a little bit of ram. The next time you hover your mouse over a server PWAD list said cache will be long gone, so no worries about having to reset ;)
User avatar (0020584)
Pol M (developer)
2019-04-30 23:46
edited on: 2019-05-01 00:02


This should give you an idea. I'm getting 0-5ms now.
EDIT: Wub, if you can, please check how this affects your setup.

User avatar (0020586)
Zalewa (developer)
2019-05-01 08:50

On Windows I don't see any significant difference between your implementation and the previous one that used the CaseInsensitiveFSFileSeeker class. In fact - it is now slightly worse as the times for servers with low WAD count are now the same as times for servers with high WAD count (but still it's just 10ms for me). The new implementation loads listings of all directories into memory (regardless of the OS), while the old implementation for Windows only checked if particular path exists case-insensitively. And - because NTFS is case-insensitive - it performed better.
User avatar (0020592)
Pol M (developer)
2019-05-01 13:49

Huh, then I'll roll back the implementation on Windows. 10ms is still excellent, but if a better option exists then we should take it.
User avatar (0020649)
Pol M (developer)
2019-05-13 19:58

User avatar (0020668)
Zalewa (developer)
2019-05-19 10:27

PR is merged (through a direct merge this time)
User avatar (0020710)
Pol M (developer)
2019-05-31 14:26
edited on: 2019-06-08 19:41

I'm experiencing some crashes with the IWAD column having the IWAD on a recursive path. I'll be working on it.
Followup commit to fix another issue: the files returned were lowercased.

User avatar (0020736)
Zalewa (developer)
2019-06-09 19:22

The fix PR merged here: [^]
User avatar (0020746)
WubTheCaptain (developer)
2019-06-12 00:36

Quote from Pol M
Wub, if you can, please check how this affects your setup.

Sorry, I haven't had time. I subscribed to this issue to remind myself, but I still haven't got around to do it. Apologies.

I'll update this ticket if and when I'll do the testing.
User avatar (0020904)
WubTheCaptain (developer)
2019-07-22 09:14

Quote from Pol M
I'm getting 0-5ms now.
EDIT: Wub, if you can, please check how this affects your setup.

I'm experiencing similar results. 1.3~beta-190720-1414 feels snappy and fast to me. So I guess this is resolved?

I didn't benchmark memory usage or anything like that.

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: No one explicitly supports this issue yet.
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2019-04-30 20:39 Pol M New Issue
2019-04-30 20:39 Pol M Status new => assigned
2019-04-30 20:39 Pol M Assigned To => Pol M
2019-04-30 20:39 Pol M Relationship added child of 0003625
2019-04-30 20:46 WubTheCaptain Severity minor => tweak
2019-04-30 20:46 WubTheCaptain Note Added: 0020579
2019-04-30 21:51 Pol M Note Added: 0020583
2019-04-30 23:46 Pol M Note Added: 0020584
2019-04-30 23:47 Pol M Note Edited: 0020584 View Revisions
2019-04-30 23:52 Pol M Status assigned => needs review
2019-05-01 00:02 Pol M Note Edited: 0020584 View Revisions
2019-05-01 08:50 Zalewa Note Added: 0020586
2019-05-01 13:49 Pol M Note Added: 0020592
2019-05-13 19:58 Pol M Note Added: 0020649
2019-05-19 10:27 Zalewa Note Added: 0020668
2019-05-19 10:27 Zalewa Status needs review => needs testing
2019-05-31 14:24 Pol M Status needs testing => assigned
2019-05-31 14:26 Pol M Note Added: 0020710
2019-06-01 11:16 Pol M Status assigned => needs review
2019-06-01 11:16 Pol M Note Edited: 0020710 View Revisions
2019-06-02 09:14 Pol M Note Edited: 0020710 View Revisions
2019-06-02 09:14 Pol M Status needs review => needs testing
2019-06-08 19:41 Pol M Note Edited: 0020710 View Revisions
2019-06-09 19:22 Zalewa Note Added: 0020736
2019-06-12 00:36 WubTheCaptain Note Added: 0020746
2019-07-22 09:14 WubTheCaptain Note Added: 0020904
2019-07-22 09:14 WubTheCaptain Status needs testing => resolved
2019-07-22 09:14 WubTheCaptain Fixed in Version => 1.3
2019-07-22 09:14 WubTheCaptain Resolution open => fixed
2019-07-30 10:13 WubTheCaptain Status resolved => closed

Questions or other issues? Contact Us.


Copyright © 2000 - 2020 MantisBT Team
Powered by Mantis Bugtracker