Author Topic: The 14 June 2024 build (13529) is out.  (Read 21482 times)

Offline Elena

  • Multiple posting newcomer
  • *
  • Posts: 61
Re: The 14 June 2024 build (13529) is out.
« Reply #15 on: January 26, 2025, 01:41:48 pm »
Hi, I hope this message will be noticed. I did not open a new topic because it is definitely related to build 13529 and over.

I also have experienced major slowdowns since b13529.
What I wanted to point out is that the culprit was indeed Browse Tracker, I disabled it and now everything is fine as before.
At the moment of writing this, current NB is 13600 and the problem is *still present*. Therefore, I simply have to keep the plugin disabled. Hope this helps.
Therefore, please consider fixing the plugin, which is causing major slowdowns since b13529

Thx
« Last Edit: January 26, 2025, 01:54:44 pm by Elena »

Offline Miguel Gimenez

  • Developer
  • Lives here!
  • *****
  • Posts: 1674
Re: The 14 June 2024 build (13529) is out.
« Reply #16 on: January 28, 2025, 12:04:44 pm »
This post describes a problem with the same commit producing the delays.

@Pecan, can you take a look?

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2842
Re: The 14 June 2024 build (13529) is out.
« Reply #17 on: January 28, 2025, 05:57:16 pm »
This post describes a problem with the same commit producing the delays.

@Pecan, can you take a look?

I'll have a look today and try to reproduce it.

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2842
Re: The 14 June 2024 build (13529) is out.
« Reply #18 on: January 31, 2025, 12:39:56 am »
Hi, I hope this message will be noticed. I did not open a new topic because it is definitely related to build 13529 and over.

I also have experienced major slowdowns since b13529.
What I wanted to point out is that the culprit was indeed Browse Tracker, I disabled it and now everything is fine as before.
At the moment of writing this, current NB is 13600 and the problem is *still present*. Therefore, I simply have to keep the plugin disabled. Hope this helps.
Therefore, please consider fixing the plugin, which is causing major slowdowns since b13529

Thx

@Elena: I apologize for missing your post.
I've reworked the Editor hook for efficiency such that only flags are set in that code and moved all processing of BrowseTracker arrays to the idle processing time routine.

Please consider retesting, since I was unable to recreate the slowdown and let us know the outcome.

CodeBlocks revision 13606.

Regards, pecan

« Last Edit: January 31, 2025, 12:49:08 am by Pecan »

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2842
Re: The 14 June 2024 build (13529) is out.
« Reply #19 on: January 31, 2025, 12:45:43 am »
This post describes a problem with the same commit producing the delays.

@Pecan, can you take a look?

I was unable to recreate the described assert and slowdown in the BrowseTracer plugin. But I've done some extensive re-coding to elimate any array processing in the editor hook and moved that processing to OnIdle().

I've also added more guards to avoid out-of-bounds conditions in the AddEditor() routine.

CB commit13606
 

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2842
Re: The 14 June 2024 build (13529) is out.
« Reply #20 on: February 15, 2025, 10:57:57 pm »
Hi, I hope this message will be noticed. I did not open a new topic because it is definitely related to build 13529 and over.

I also have experienced major slowdowns since b13529.
What I wanted to point out is that the culprit was indeed Browse Tracker, I disabled it and now everything is fine as before.
At the moment of writing this, current NB is 13600 and the problem is *still present*. Therefore, I simply have to keep the plugin disabled. Hope this helps.
Therefore, please consider fixing the plugin, which is causing major slowdowns since b13529

Thx

Fixed svn 13612.

The actual slowdown culprit was CodeCompletion  (CC) "Parse while typing" setting. However when the user disabled settings while a project was loaded, CC clobbered the settings back to the older condition as the project was closed.

Although the fix preserves the users settings in the .conf (global settings) the user will still have to re-parse the projects/files in order to apply the changed CodeCompletion global settings to the projects or files.

The easiest way to do that is to close and reopen the workspace or right-click on a project in the workspace tree and select 'Reparse this project'.
« Last Edit: February 15, 2025, 11:04:20 pm by Pecan »

Offline Elena

  • Multiple posting newcomer
  • *
  • Posts: 61
Re: The 14 June 2024 build (13529) is out.
« Reply #21 on: February 15, 2025, 11:10:15 pm »
Hi, thanks for your support. Since at present I am not equipped to compile C::B I will surely test once the new NB binary is ready (it seems there haven't been any new NB since December btw)

Offline Miguel Gimenez

  • Developer
  • Lives here!
  • *****
  • Posts: 1674
Re: The 14 June 2024 build (13529) is out.
« Reply #22 on: Yesterday at 11:35:39 am »
The text in Parser::ShowGlobalChangeAnnoyingMsg() should allow translation, something like this:
Code
warningMsg = _("The global settings change does not take effect\n"
               "until the projects are either reloaded or reparsed.\n\n"
               "You can selectively reparse projects by right clicking\n"
               "on the project title in the Workspace tree and selecting\n"
               "'Reparse current project'.");

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6072
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 14 June 2024 build (13529) is out.
« Reply #23 on: Today at 01:51:04 pm »
The text in Parser::ShowGlobalChangeAnnoyingMsg() should allow translation, something like this:
Code
warningMsg = _("The global settings change does not take effect\n"
               "until the projects are either reloaded or reparsed.\n\n"
               "You can selectively reparse projects by right clicking\n"
               "on the project title in the Workspace tree and selecting\n"
               "'Reparse current project'.");

I have fixed that in the SVN now, thanks.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.