Jump to content

Vincent Parrett

Members
  • Content Count

    335
  • Joined

  • Last visited

  • Days Won

    16

Everything posted by Vincent Parrett

  1. Vincent Parrett

    MAP2PDB - Profiling with VTune

    It wasn't that, and I probably did forget the bind switch before I sent it to you, however with the new version.... we have lift off! Awesome work! E:\map2pdb>map2pdb.exe I:\FBAT_HG9\Output\FB9\FinalBuilder9.map -v -bind:I:\FBAT_HG9\Output\FB9\FinalBuilder9.exe map2pdb - Copyright (c) 2021 Anders Melander Version 2.0 Constructed a new PDB GUID: {CE1E6D08-67E6-4B5B-B42A-3FC719254F1E} Output filename not specified. Defaulting to FinalBuilder9.pdb Reading MAP file - Segments Warning: [ 8] Empty segment: .pdata [0006:00400000] - Modules - Symbols Warning: [20671] Failed to resolve symbol to module: [0005:00000608] SysInit.TlsLast Warning: [20673] Failed to resolve symbol to module: [0004:FF77A000] SysInit.__ImageBase - Line numbers Warning: [71563] Line number with zero offset ignored. Module:VSoft.IDE.Types, Segment:0001, Source:VSoft.IDE.Types.pas, Line:49 Warning: [71567] Line number with zero offset ignored. Module:VSoft.IDE.Interfaces, Segment:0001, Source:VSoft.IDE.Interfaces.pas, Line:328 Warning: [75481] Line number with zero offset ignored. Module:LMDRTLConst, Segment:0001, Source:LMDRTLConst.pas, Line:213 Warning: [75621] Line number with zero offset ignored. Module:intfLMDBase, Segment:0001, Source:intfLMDBase.pas, Line:44 Warning: [76980] Line number with zero offset ignored. Module:LMDDckCst, Segment:0001, Source:LMDDckCst.pas, Line:29 Warning: [79649] Line number with zero offset ignored. Module:VSoft.IDE.ActionListInterfaces, Segment:0001, Source:VSoft.IDE.ActionListInterfaces.pas, Line:136 Warning: [90056] Line number with zero offset ignored. Module:SynEditStrConst, Segment:0001, Source:SynEditStrConst.pas, Line:577 Warning: [98436] Line number with zero offset ignored. Module:VSoft.IDE.WizardManagerService, Segment:0001, Source:VSoft.IDE.WizardManagerService.pas, Line:61 Warning: [99799] Line number with zero offset ignored. Module:dwTaskbarList, Segment:0001, Source:dwTaskbarList.pas, Line:213 Warning: [103835] Line number with zero offset ignored. Module:RestException, Segment:0001, Source:RestException.pas, Line:26 Warning: [105461] Line number with zero offset ignored. Module:VSoft.Shared.UXLControlIntf, Segment:0001, Source:VSoft.Shared.UXLControlIntf.pas, Line:60 Warning: [107033] Line number with zero offset ignored. Module:VSoft.IDE.MS.ActionCollection.Interfaces, Segment:0001, Source:VSoft.IDE.MS.ActionCollection.Interfaces.pas, Line:1085 Constructing PDB file - Collecting source file names - Module streams - Strings stream - PDB Info stream - TPI stream - Symbols stream - DBI stream - IPI stream - Finalizing PDB file Patching PE file - PE32 image (32-bit) - PDB file name has been stored in debug data. - Header checksum has been cleared. - PE file has been updated. I was also able to create a pdb for the package E:\map2pdb>map2pdb.exe I:\FBAT_HG9\Output\FB9\VSoft.Core.map -bind:I:\FBAT_HG9\Output\FB9\VSoft.Core.bpl -v map2pdb - Copyright (c) 2021 Anders Melander Version 2.0 Constructed a new PDB GUID: {76323C0F-0787-44F8-BC72-2B6ACC9CBF82} Output filename not specified. Defaulting to VSoft.Core.pdb Reading MAP file - Segments Warning: [ 7] Empty segment: .tls [0005:00000000] Warning: [ 8] Empty segment: .pdata [0006:00400000] - Modules Warning: [ 1682] Module exceed segment bounds - ignored: OtlCommon.Utils [0005:00000000+256] - Symbols Warning: [ 6403] Failed to resolve symbol to module: [0005:00000000] OtlCommon.Utils.LastThreadName Warning: [ 8705] Failed to resolve symbol to module: [0005:00000100] SysInit.TlsLast Warning: [ 8709] Failed to resolve symbol to module: [0004:FFBF8000] SysInit.__ImageBase - Line numbers Warning: [64147] Line number offset out of range for module. Offset:003DAEEF, Module:.VSoft.Core [003DAEF0 - 003E5738] Constructing PDB file - Collecting source file names - Module streams - Strings stream - PDB Info stream - TPI stream - Symbols stream - DBI stream - IPI stream - Finalizing PDB file Patching PE file - PE32 image (32-bit) - PDB file name has been stored in debug data. - Header checksum has been cleared. - PE file has been updated. Now to hook it into every project in the group and see how it goes 😃 Thanks again for this awesome effort.. my only question now is, if you can do this in your spare time, why TF can't embarcadero do it 🙄
  2. Vincent Parrett

    MAP2PDB - Profiling with VTune

    I compiled map2pdb from source using 10.4.2 and vtune now loads the pdb from the test project. Sadly it didn't work for my real application Cannot locate debugging information for file 'I:\FBAT_HG9\Output\FB9\FinalBuilder9.exe'. Cannot match the module with the symbol file 'I:\FBAT_HG9\Output\FB9\FinalBuilder9.pdb'. Make sure to specify the correct path to the symbol file in the Binary/Symbol Search list of directories.
  3. Vincent Parrett

    MAP2PDB - Profiling with VTune

    Well I tried the same project with 10.3 and got the same result, so it's not the compiler version. I'm using Vtune 2021.1.1 Gold - perhaps it's the vtune version?
  4. Vincent Parrett

    MAP2PDB - Profiling with VTune

    I suspect this has to do with the compiler version, using 10.4.2 even the test console app doesn't show function names. Project3.zip
  5. Vincent Parrett

    MAP2PDB - Profiling with VTune

    I have pm'd the map file, I didn't have your email address handy.
  6. Vincent Parrett

    MAP2PDB - Profiling with VTune

    I was seriously excited about this, until I realized I don't really know how to drive vtune 🙄 (terrible user interface!). So I was able to generate a pdb (9.5MB) and it appears to bind, however when running with vtune I don't see function names CPU Time 1 of 1: 100.0% (0.010s of 0.010s) FinalBuilder9.exe ! func@0x77c258 - [unknown source file] FinalBuilder9.exe ! func@0x4de4bf + 0xca - [unknown source file] FinalBuilder9.exe ! func@0x4ea8f8 + 0x176 - [unknown source file] FinalBuilder9.exe ! func@0x4ea518 + 0x10c - [unknown source file] FinalBuilder9.exe ! func@0x4ea8f8 + 0xf5 - [unknown source file] FinalBuilder9.exe ! func@0x4ea518 + 0x10c - [unknown source file] FinalBuilder9.exe ! func@0x4ea8f8 + 0xf5 - [unknown source file] FinalBuilder9.exe ! func@0x4ea518 + 0x10c - [unknown source file] FinalBuilder9.exe ! func@0x4ea8f8 + 0xf5 - [unknown source file] FinalBuilder9.exe ! func@0x4ea518 + 0x10c - [unknown source file] ..... How can I see if vtune is actually using the pdb? Also I'm using runtime packages, however when I tried to create a pdb for packages map2pdb crashed E:\map2pdb>map2pdb.exe I:\FBAT_HG9\Output\FB9\VSoft.Core.map -bind:I:\FBAT_HG9\Output\FB9\VSoft.Core.bpl -v map2pdb - Copyright (c) 2021 Anders Melander Version 2.0 Output filename not specified. Defaulting to VSoft.Core.pdb Reading MAP file - Segments - Modules An error occurred in the application. date/time : 2021-04-04, 08:53:18, 171ms computer name : SR22 user name : vincent registered owner : Vincent operating system : Windows 10 x64 build 19042 system language : English system up time : 42 minutes 16 seconds program up time : 185 milliseconds processors : 8x Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz physical memory : 52813/65477 MB (free/total) free disk space : (C:) 78.24 GB (E:) 233.56 GB display mode : 2560x1440, 32 bit process id : $55d0 allocated memory : 118.39 MB largest free block : 1.47 GB command line : map2pdb.exe I:\FBAT_HG9\Output\FB9\VSoft.Core.map -bind:I:\FBAT_HG9\Output\FB9\VSoft.Core.bpl -v executable : map2pdb.exe exec. date/time : 2021-04-04 08:00 compiled with : Delphi 10.3 Rio madExcept version : 5.1.0 callstack crc : $7846b8db, $f263fd00, $f263fd00 exception number : 1 exception class : EArgumentOutOfRangeException exception message : Argument out of range. thread $5a5c: 0046c541 +029 map2pdb.exe debug.info TDebugInfoSegments.FindByIndex 0047e90f +58b map2pdb.exe debug.info.reader.map TDebugInfoMapReader.LoadFromStream 0047d844 +034 map2pdb.exe debug.info.reader TDebugInfoReader.LoadFromFile 004aa13e +2e6 map2pdb.exe map2pdb 140 +62 initialization 76dffa27 +017 KERNEL32.DLL BaseThreadInitThunk thread $5c8: 76dffa27 +17 KERNEL32.DLL BaseThreadInitThunk thread $55d8: 76dffa27 +17 KERNEL32.DLL BaseThreadInitThunk thread $5b2c: 76dffa27 +17 KERNEL32.DLL BaseThreadInitThunk thread $4fac: 76dffa27 +17 KERNEL32.DLL BaseThreadInitThunk thread $5bc0: 76dffa27 +17 KERNEL32.DLL BaseThreadInitThunk
  7. It's not that I don't care for it, I just don't have the time (or skills for it). Happy to look at contributions to achieve this. I do know there are some issues with constructor overloads that would need to be addressed.
  8. Ok, that's news to me (DUnitX author). 😉
  9. Vincent Parrett

    VCL Handling of dpi changes - poor performance

    Is it just my delphi applications that behave poorly when handling dpi changes? This is when setting high dpi in the manifest to PerMonitorV2. I have verified that the controls (many of them mine) are handling this as they should (override ChangeScale). When dragging the application between monitors with different dpi's, it takes 3-4 seconds while the window flickers and repaints multiple times - the dragging operation pauses while it does this, and then the window eventually jumps to where you actually dragged it. I've been looking at other applications (that ssupport PerMonitorV2) to see how they behave, even explorer stutters a little, due I guess to the ribbon control - but the stutter is around the 200ms mark. Thunderbird seem to repaint twice but very fast. After some debugging, as far as I can tell, this is caused by all controls getting their ChangeScale method called (as you would expect) which results in calls to SetBounds, which invalidates the control causing more painting! TWinControl.ScaleControlsForDpi appears to be doing the right thing (control alignment is a perf hog), but calling EnableAlign inevitably invalidates the control, again. procedure TWinControl.ScaleControlsForDpi(NewPPI: Integer); var I: Integer; begin DisableAlign; try for I := 0 to ControlCount - 1 do Controls[I].ScaleForPPI(NewPPI); finally EnableAlign; end; end; This really show up an inherent design flaw in the vcl, there is no BeginUpdate/EndUpdate design pattern in the vcl that allows a control (or form) to disable child controls painting until it's done. Many controls implement this pattern individually, but that doesn't help in this scenario. The situation isn't helped by my using Vcl Themes either - resize (setbounds) causes serious flicker in some controls and I'm sure this is coming into play here too. I tried to fudge a BeginUpdate/EndUpdate with this : procedure TMainForm.WMDpiChanged(var Message: TWMDpi); begin SendMessage(Self.Handle, WM_SETREDRAW, NativeUInt(False), 0); try inherited; finally SendMessage(Self.Handle, WM_SETREDRAW, NativeUInt(true), 0); RedrawWindow(Self.Handle, nil, 0, RDW_INVALIDATE or RDW_UPDATENOW or RDW_ALLCHILDREN); end; end; It cut's out the visible repainting, but doesn't speed things up much If anyone has any ideas on how to tackle this I'm all ears.
  10. Vincent Parrett

    VCL Handling of dpi changes - poor performance

    Yes, the project started in Delphi 5, been upgraded a few times over the years, so not sure when that property was set but it did take a while to figure out what was going on.
  11. Vincent Parrett

    VCL Handling of dpi changes - poor performance

    Just a word of warning about setting ParentFont := true - I had ParentFont := true on a base form class and this completely disabled scaling on all the descendant forms! This just took me an hour of messing around to reproduce in a test project. I have no idea why ParentFont was set on that form - the project is 20yrs old and I've changed version control several times over the years so couldn't find the commit where that was set. Not sure if this is expected behaviour on forms or a bug.
  12. Vincent Parrett

    VCL Handling of dpi changes - poor performance

    You would think so, however, VCL Styles were added in XE2 and I think it wasn't until 10.3 they were added to the IDE, and even then the IDE is using custom themes (notice we can't just select any vcl theme). So they don't have a great track record of dogfooding new features.
  13. Vincent Parrett

    Determining why Delphi App Hangs

    @ewong You should not, under any circumstances, update vcl controls in a thread other than the main thread. If it's just updating a progress bar, you can do that quite simply by using PostMessage and send a user message to the form https://www.cryer.co.uk/brian/delphi/howto_send_custom_window_message.htm Use PostMessage (non blocking) rather than SendMessage (blocking). Working with threads in Delphi is harder than it needs to be. I recommend taking a look at https://github.com/gabr42/OmniThreadLibrary I also created a nice wrapper for omnithread that makes running tasks in background threads really simple : https://github.com/VSoftTechnologies/VSoft.Awaitable I've been using this in my projects for a while now (I was already using OmniThread) and it makes things so much simpler!
  14. Vincent Parrett

    Introducing Delphi Uses Helper

    And I have to say, Why TF isn't something like this built into the IDE?? Nice work. It almost feels like I'm using visual studio 2012 I ended up using Shift+Ctrl+U as the shortcut so I never have to see the crappy default one - which I accidently invoked a few times now. Now for the first feature request 😉. Can you index my project search path? I just tried to us it to add Spring.Collections - but that is installed via dpm - so it's on my search path (via an msbuild property). This tool as a ton of potential... I know you don't have the time to work on it but others might, if you put it on github 😉
  15. Vincent Parrett

    Introducing Delphi Uses Helper

    Huh, restarted the IDE again (third time) and now it works. Nice!
  16. Vincent Parrett

    Introducing Delphi Uses Helper

    I tried, but cannot get it to show. Shift+Ctr+A just locks the IDE for about 20 seconds and then the default uses thingy (I forgot how bad it is) shows. I tried changing the shortcut but then nothing happens. Testing with 10.4.2
  17. Vincent Parrett

    VCL Handling of dpi changes - poor performance

    One last one before I give up for the day.. I added a few more outputdebugstring calls. Debug Output: TForm3.WMDpiChanged - dpi : 144 Process HighDPIDragTest.exe (52784) Debug Output: TForm3.Paint Process HighDPIDragTest.exe (52784) Debug Output: TMyPanel.AlignControls - dpi : 144 Process HighDPIDragTest.exe (52784) Debug Output: TForm3.AlignControls - dpi : 144 Process HighDPIDragTest.exe (52784) Debug Output: TForm3.Paint Process HighDPIDragTest.exe (52784) Debug Output: TMyPanel.AlignControls - dpi : 144 Process HighDPIDragTest.exe (52784) Debug Output: TForm3.WMSize- before inherited - dpi : 144 Process HighDPIDragTest.exe (52784) Debug Output: TForm3.AlignControls - dpi : 144 Process HighDPIDragTest.exe (52784) Debug Output: TForm3.WMSize - after inherited Process HighDPIDragTest.exe (52784) Debug Output: TForm3.WMSize- before inherited - dpi : 144 Process HighDPIDragTest.exe (52784) Debug Output: TForm3.AlignControls - dpi : 144 Process HighDPIDragTest.exe (52784) Debug Output: TMyPanel.AlignControls - dpi : 144 Process HighDPIDragTest.exe (52784) Debug Output: TForm3.WMSize - after inherited Process HighDPIDragTest.exe (52784) Debug Output: TForm3.AlignControls - dpi : 144 Process HighDPIDragTest.exe (52784) Debug Output: TForm3.Paint Process HighDPIDragTest.exe (52784) Debug Output: TForm3.Paint Process HighDPIDragTest.exe (52784) Debug Output: TForm3.Paint Process HighDPIDragTest.exe (52784) Debug Output: TMyPanel.Paint Process HighDPIDragTest.exe (52784) All that painting doesn't make it look any prettier 🙄 This doesn't look to be something that can be fixed with a patch or detour etc, it's going to take a rewrite of swathes of the vcl code
  18. Vincent Parrett

    VCL Handling of dpi changes - poor performance

    Ok, so I can definitively say this is a design flaw in the VCL - we are not doing anything wrong. The bug is in TCustomForm.ScaleForPPIRect the call to ScaleControlsForDpi(NewPPI) causes AlignControls to be called on the child controls and the form (depth first) - which is fine, and expected. My debug output looks like this : Debug Output: TMyPanel.AlignControls - dpi : 144 Process HighDPIDragTest.exe (3164) Debug Output: TForm3.AlignControls - dpi : 144 Process HighDPIDragTest.exe (3164) Then a few lines further down in TCustomForm.ScaleForPPIRect, it calls SetBounds and all hell breaks loose! Debug Output: TForm3.WMSize- before inherited - dpi : 144 Process HighDPIDragTest.exe (3164) Debug Output: TForm3.AlignControls - dpi : 144 Process HighDPIDragTest.exe (3164) Debug Output: TForm3.WMSize - after inherited Process HighDPIDragTest.exe (3164) Debug Output: TForm3.WMSize- before inherited - dpi : 144 Process HighDPIDragTest.exe (3164) Debug Output: TForm3.AlignControls - dpi : 144 Process HighDPIDragTest.exe (3164) Debug Output: TMyPanel.AlignControls - dpi : 144 Process HighDPIDragTest.exe (3164) Debug Output: TForm3.WMSize - after inherited Process HighDPIDragTest.exe (3164) Then it calls Realign Debug Output: TForm3.AlignControls - dpi : 144 Process HighDPIDragTest.exe (55256) So the form's AlignControls method is called 3 times, and on the panel 3 times! It should be noted that the number of times for each control depends on it or other child controls anchor or align settings (see Vcl.Controls AlignWork function), It's no wonder that things look so bad, it's because they are. Testing in 10.4.2 with VCL Styles enabled - but the code looks the same for 10.3 so this is not new.
  19. Vincent Parrett

    VCL Handling of dpi changes - poor performance

    I spent some more time looking at this and I can only describe it as a clusterf*ck. The issue is that as the application crosses over monitors, the form receives a WM_SIZE message, which calls AlignControls (which on a complex form or container control can be very slow). Cue mega rearranging of controls and repainting. Then the application received WM_DPICHANGED, which calls SetBounds, ChangeScale (which calls AlignControls) and more arranging and repainting occurs. Then add VCL Styles into the mix - for some reason with VCL Styles that WM_SIZE get's sent twice, and then the WM_DPICHANGED is sent. I have no idea why it's sent twice, but I doubt windows is doing it. I'm not even sure windows is sending the WM_SIZE at all (still investigating this). Anyway, the upshot of this is the more controls you have on a form the worse this issue will be.
  20. Vincent Parrett

    VCL Handling of dpi changes - poor performance

    I already had that in place, but in this case enabling/disabling that didn't seem to make much difference. LOL! I had forgotten about that thread (which I posted in), and it didn't come up when I was searching. FWIW, LockWindowUpdate did work for me in the WMDpiChanged handler - but setredraw seemed slightly safer. I've been trying to profile what is happening but the lack of a decent profiler is killing me! I've been using the sampling profiler, and it does show AlignControls showing up a lot (which is a known performance issue), need to investigate further.
  21. Vincent Parrett

    Min & Max

    Gotta support all those 386's that are still floating around 🙄 voted.
  22. So you should be able to make a reproducible test case - in case there is none already. I did report this with a reproducible test case, but they knew about it long before then. https://quality.embarcadero.com/browse/RSP-32666
  23. Vincent Parrett

    Can't load LivePreview270.bpl

    I got the same issue, but since Live Preview is a firemonkey/mobile thing which I don't use, I just clicked on No and moved on! My guess is it's linked to one of the Indy bpl's, and the only choice you have is a) undo what you did or b) Lose the feature. I annoys me how the IDE ships with and depends on Indy, If they use it, they should take a private copy of the library (ie rename the units) - that way we are free to update Indy without jumping through hoops.. pretty much the first thing I do after installing delphi is remove Indy (so I can use a later or known version).
  24. Hi All Some changes with the IDE integration this week. I was unsatisfied with how the IDE plugin behaved when working with large project groups, because the Messages View doesn't show until the project group has loaded. When restoring the first time on a machine that didn't have the packages, this resulted in a potentially long period (depending on how many packages need to be installed/compiled) where no status info is available to what's going on, making it appear as though the IDE had hung. So I decided to use a window (not modal) to show the log view as the projects are loading and packages restoring. I created a custom LogMemo component to show this since I couldn't find one that suited - fortunately I already had some code to base it off (VSoft.VirtualListView). The log window will auto close after a few seconds if the restore/install/uninstall succeeds, you can configure that auto close time in the options. I also added options so you can control when the log view shows. Lastly, I added an option to not add DPM nodes to the project manager tree. On large project groups (the FinalBuilder project group has over 100 projects) it causes a long delay before the IDE is ready to use. This is because of how I had to hack into the IDE to add the nodes, the code is not at all efficient. When time permits I'll revisit this and see if I can find a better way. https://github.com/DelphiPackageManager/DPM/releases/tag/v0.1.63-alpha
  25. Vincent Parrett

    DPM Package Manager Progress - 15 March 2021

    Hi All As a follow up to the previous post, I have uploaded a new build : https://github.com/DelphiPackageManager/DPM/releases/tag/v0.1.64-alpha This build has a dramatic performance improvement when it comes to adding nodes to the Project Manager tree - it now has very little impact on project load times. Achieved by caching Rtti.
×