Menu

#100 Performance issues

v4.4.5
closed
v4.4.7 (10)
6
2019-04-05
2017-07-18
Anonymous
No

Hello Jackslade,

I have found some performance issues while searching in text files.

  1. Issue in method ReceiveFileEncodingDetected. When file encoding is found a whole Log is searched to find find recently added element. In this case searching is perfomed form begin to end of LogItems. As I have checked in most cases elements to replace are located at the end of this list and only one element is found so you can try to find elements from end to begin and exit loop after finding element.

  2. The Grep thread waits for UI thread after each checked file. In method ReceiveSearchingFile for each file is a truncated file name is computed. There are two thins not ok. First the function TruncateFileName is very slow becouse it uses very slow method MeasureString and creates Graphics object with is also slow, it can be fixed by using monospaced fonts (eg. Conolas) or by moving MeasureSting to status bar Paint event which will be executed when needed. Second thing is using XPath to get translation string from Xml file.

For example when we have 100k files of size 1kb almost 90% of time is spent on updating UI. You can check it by disabling TruncateFileName. In attachement I have created solution in wich I reduce UI refresh rate to 30 refeshes/s by using single element queue and Timer which shows value in some constant periods.

  1. The number of LogItem type is found by analysing whole LogItems list in GetLogItemsCountByType which is used in refreshing UI. It can be computed incrementaly during searching.

Bonus: I have changed "File extension" filter to contain set of extensions separated by semicolon.

Best regards,
Tobek

1 Attachments

Discussion

  • Jackslade

    Jackslade - 2017-08-15
    • status: open --> accepted
     
  • Jackslade

    Jackslade - 2019-04-05
    • Labels: --> v4.4.7
    • Status: accepted --> closed
     

Anonymous
Anonymous

Add attachments
Cancel