Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Work in Progress / PerfAnDBPro (Performance Analyser for DBPro)

Author
Message
Phjon
18
Years of Service
User Offline
Joined: 28th Nov 2005
Location:
Posted: 29th Nov 2009 16:09 Edited at: 29th Nov 2009 16:12
GIDustin,

I was wondering when someone would write their own precompilers that worked with my assistant. Just a little suggestion with those - you may want to add in an "If" statement that checks to see whether a source code file is actually present in the command line. I have one with PerfAnDBPro that tells me if such an event has occured, and it saves relying on the standard DBPro error message that comes up by default.

I can see that you've used some of my code that checks how many lines there are in the source code. I have recently discovered that a similar setup for determining the number of lines of code that are present in a loaded .dat file is in fact taking up quite a lot of time in the data viewer loading section. I still need to look at the performance data further, but this might be an area for optimisation, but then again, other parts of the code may require more attention.

I have also been working on your request for the assistant, but I am running into some problems in determining when/if the user clicks the "Cancel" button to stop the compilation process. I've found some VB code that can detect Windows system messages like "WM_CLOSE", but none of the messages that I have tried seem to be received by the assistant when the "Cancel" button is pressed.

The assistant must receive something, as it closes down when asked, but at the moment, I don't know what that something is.
GIDustin
15
Years of Service
User Offline
Joined: 30th May 2008
Location:
Posted: 29th Nov 2009 20:34 Edited at: 29th Nov 2009 20:57
Got another problem for ya (don't hate me). Using PerfAnDBPro v0_2_1beta.

It looks as though PerfAnDBPro loops the code removing REM lines. It is, however, missing REM lines that are ONLY REM lines:



Edit: Even the forum syntax highlighter doesn't recognize those lines.

It removes the first, second, and fourth line, but the third and fifth stay in the project and Performance code is added to it. Might be a problem there since the performance code before it is run, but the code after most likely is not since it follows a REM statement:






Then I have the problem of the Randomly Moved REM lines. This is part of my GUI system, making a dialog box to allow the user to set the options:


OK, so I have the function XP_MainMenu_AdvOptions_Display(), followed by 3 more functions. The next source file in compile order is the file that actually creates the window, XP_GUI.dba. It begins with:


Now, take a gander at this code after PerfAnDBPro has it's way with it:



Edit: Added syntax highlighting so you can find the problem. Look for green text
This code starts off in XP_MainMenu_AdvOptions_Display() shown above, but right at the end you will see the first comment line from the next source file...

Hope this helps.

Edit: This same thing happens at the end of each source file that precedes a source file with comments like the ones above.

What is really strange is the the 2 empty REM lines inside each of those blocks remain where they should be in the code file, but the REM lines with actual data fly up 60+ lines of code.:



GIDustin
15
Years of Service
User Offline
Joined: 30th May 2008
Location:
Posted: 29th Nov 2009 21:03 Edited at: 29th Nov 2009 21:06
Found another problem unrelated to the previous.


It treats the ":" after labels as if it were a command seperator:


Edit: scrolling the final source file shows that 50% were done correctly, 50% were not

Phjon
18
Years of Service
User Offline
Joined: 28th Nov 2005
Location:
Posted: 29th Nov 2009 21:24
GIDustin,

Thanks for the bug reports, and don't worry about finding them, that's what the beta stage is supposed to be about - finding bugs and me fixing them. I've found a couple more myself over the past couple of days; one of them is a little similar to one of the bugs you've found.

As the number of bugs that have been found (and have been fixed) is getting rather numerous, I'm considering writing a batch program that checks every bug report to ensure that any recent fixes made haven't broken any previous fixes. This should save both on the time taken to ensure that the PerfAnDBPro system works, and on my memory, which is beginning to forget checking previous bug fixes.
Phjon
18
Years of Service
User Offline
Joined: 28th Nov 2005
Location:
Posted: 1st Dec 2009 16:13 Edited at: 1st Dec 2009 23:11
GIDustin,

My progress on solving that issue with the precompiler assistant has not gone very well I'm afraid. I've tried a number of different techniques, including trapping Windows messages receieved by the assistant, creating an interface program that goes between the IDE and the assistant (on the grounds that I could detect when the interface program closed), and some other ideas, but none seemed to have worked.

I'm theorising that, although the assistant has control over when to start the DBPro compiler, it doesn't have any control in terms of handling messages sent by it and above all, closing it down. I also theorise that the window class "TDBPEDITOR" (I think) is the one and only window the DBPro compiler communicates with, rather than my assistant.

Strangely, it seems that if I program the assistant to close or kill the compiler when it is running, it just comes back to life again, continuing where it left off. I know the code must be doing something as I put a message box in the way to confirm when it was closing the compiler. Nonetheless, the compiler kept on running.

It looks as if I may not be able to do anything about this, unless anyone with good experience with the DBPro compiler, the "TDBPROEDITOR" window or VB 2008 has any tricks up their sleeves to solve this.

-------------------------------------------

Not the sort of news that I wanted to send out, just as I get a mention in this month's newsletter!

===========================================

As a result of the above, I have decided to move back to fixing bugs with the PerfAnDBPro precompiler and the data viewer. I need to write the batch program that should ease the bug checking process, and then take a look at a small bit of optimisation.

I will post up the new versions of these programs as soon as they're ready.

I also invite any new readers of this thread to download the PerfAnDBPro system and give it a go. Just remember to back up any source code, and projects beforehand. Please post if you find any bugs, or if you have any ideas for improving the system.

===========================================
Small set of updates:

It took me a while to get it to execute the DBPro compiler correctly, but I now have the batch processing program constructed and operational.

-------------------------------------------
GIDustin,

Your second post with the label bug in it was actually producing the same problems as the "Gosub Demo" code when I ran that to double-check the fault. In any case, that bug has now been fixed.
Phjon
18
Years of Service
User Offline
Joined: 28th Nov 2005
Location:
Posted: 5th Dec 2009 22:31
Update 5/12/09

I have finally managed to fix the recent bugs the GIDustin found. The reason why it has taken me so long is because I had to do a complete re-write of the line destacking function in order to fix the problems. Re-writing that function and testing it has taken me ages, and has been somewhat frustrating at times. However, it now works (more or less) and I'm ready to release an update of the precompiler.

Please note that there is a slight issue with code indentation of destacked lines. This can be seen in the data viewer, as some lines will be shown as being on the left-hand edge of the code listing. I don't believe that this is anything more than a cosmetic issue, and should be fixed when I complete the optimisation work on the system:

The update to the precompiler can be obtained from the usual place; we are now on version 0.2.2 beta.

======================================================

It has come to my attention that you cannot open the data viewer to view .dat files because it cannot find a particular file. This file is the settings file, and for the past few versions, it has been called "Settings.cfg" rather than "PADVSettings.cfg"! My apologies for this - a replacement version of the data version is now available. I've kept the version number the same, as it was simply an oversight, the version is 0.2.2 beta.
Phjon
18
Years of Service
User Offline
Joined: 28th Nov 2005
Location:
Posted: 6th Dec 2009 19:08
Update 6/12/09

New versions of the precompiler and data viewer are out. The fixes include, amongst other things,

Cosmetic issues with code indentation have now been fixed.
The time taken by the data viewer to load in files has been reduced by about 20% (1st pass at optimising the data viewer).
As far as I can tell, all the bugs that have been reported so far seem to have been fixed (my batch processor reports no faults with the profiled versions of the bugs that have neen raised).

We are on versions 0.2.3 beta for both the precompiler and the data viewer.

==================================================

Knowing my luck, there may be one or two more bugs out there to find. If anyone does find any, please post up a code snippet that encapsulates the bug, and I'll take a look at it. Having said that, the system seems to be behaving itself a bit better than it was a week or so ago.
Phjon
18
Years of Service
User Offline
Joined: 28th Nov 2005
Location:
Posted: 16th Dec 2009 21:33
Progress report, 16/12/09

Well, folks may be wondering why things have been a bit quiet on this thread recently. This is mainly due to the fact that my work productivity seems to go down over the winter, and strangely, now that I'm in my Christmas break, the work pace has slowed down some more.

I have recently been working on the precompiler assistant, and have been trying to implement features such as loading/saving precompiler lists, and putting in place a feature that allows you to enable/disable precompilers from the running list by checking/unchecking boxes in the list. Unfortunately, it would seem that the event VB calls when a check box in the list is clicked doesn't seem to update the internal status of the items, only the external status, so when one "checks" a precompiler, and then compiles a DBPro executable, the precompiler won't be run. Conversly, if it is already checked, and you de-activate it, the precompiler assistant runs it anyway. Very frustrating!

----------------------------------------------------------------

There are some things, aside from updating the precompiler assistant that I would like to put in place before I fully release the system:

In the data viewer, add a coloumn to show the number of times a line of code has been executed
Optimise the data viewer further
Move the right hand coloumn in slightly, as some of the numbers are being clipped at the edge
Make some new help files
Add a feature that allows you to profile all and only function/gosub blocks

With the last feature, I'm slightly concerned that people may focus on optimising their programs in functions and gosubs only, even though what may be causing the main slowdowns in their programs may be elsewhere in their code (i.e. not in a function or a gosub). Nonetheless, I will add it anyway.

In addition, there are some things that I would like to add in in future versions of PerfAnDBPro, but will be added in versions after the official release.

----------------------------------------------------------------

When I can get over the winter cabin fever (and the frustration), I'll be posting up an update to the assistant, and other programs as soon as I can.
GIDustin
15
Years of Service
User Offline
Joined: 30th May 2008
Location:
Posted: 20th Dec 2009 07:40
Quote: "I can see that you've used some of my code that checks how many lines there are in the source code. I have recently discovered that a similar setup for determining the number of lines of code that are present in a loaded .dat file is in fact taking up quite a lot of time in the data viewer loading section. I still need to look at the performance data further, but this might be an area for optimisation, but then again, other parts of the code may require more attention.
"


Just curious on if/how you managed to speed this up. I only use your Performance precompiler on major builds, but I use my 2 custom precompilers on every build and they are taking a fair amount of time to run and it appears to be loading and saving the file.

- GIDustin

Login to post a reply

Server time is: 2024-04-26 16:47:31
Your offset time is: 2024-04-26 16:47:31