Hi, I was trying profiling on the example program given @ here <https://www.freetype.org/freetype2/docs/tutorial/example1.c>. I have used the profiling tool inbuilt in Visual Studios but was unable to extract useful information from it, therefore I have tried a solution provided on Stack Overflow @ here <https://stackoverflow.com/questions/5248915/execution-time-of-c-program> . It basically uses `clock()` function to calculate the running time of the program. So, basically I have used two variables of type *time_t *one at the start and one at the end of the program marking the clock time at those steps and in the end the program prints the time taken by the program in seconds. For averaging out the result I have used a *for *loop running the example code 10 times every time the code is is executed and at the end of each iteration it writes the difference between the start time and end time to a file in seconds. I have attached the file in which it writes the results. I have tested the above solution on Ubuntu 20.04 LTS and got the following results: No Debugging mode (avg time: 0.0164531 sec) Debugging using FT_DEBUG_LEVEL_TRACE mode (avg time: 0.0988122 sec) Debugging using FT_LOGGING mode (avg time: 0.0512144)
Please look into this and provide feedback... Thanks, Priyesh On Tue, Jul 14, 2020 at 4:43 PM Priyesh kumar <[email protected]> wrote: > Hi again, > I accidentally sent the previous mail > Continuing to the previous mail... > Also in the requirements, you told me to provide an option in MakeFile > `make dist` to build the > external library. But dlg uses meson build system and I don't have any > idea how to combine > meson build system with MakeFile, therefore could you provide me some > references from where > I can read about doing this... > > Thanks, > Priyesh > > On Tue, Jul 14, 2020 at 4:37 PM Priyesh kumar <[email protected]> > wrote: > >> Hi, >> I have added an option in `FT2_DEBUG` environment variable to >> enable/disable the >> printing of FT_COMPONENT and Timestamp with a log message. >> The discussion related to dlg's features is still going, therefore in the >> meantime I was >> thinking of extending the support on Windows. >> After looking: builds/windows/vc2010 , builds/windows/visualc >> and builds/windows/visulace >> I can see that they all depend on builds/windows/ftdebug.c, therefore I >> wanted to ask that >> Do I have to change only this file or there are some other files that I >> have to take care of? >> >> Also in the requirements, you told me to provide an option in MakeFile >> `make dist >> >> On Sun, Jul 12, 2020 at 2:50 PM Priyesh kumar <[email protected]> >> wrote: >> >>> Hi armin, >>> >>> *> This would print wrong-ish timestamps that couldn't really be used >>> for profiling (I mean, it could; you just have to know which timestamp >>> belongs to which message). I would suggest to * >>> *> rather store a flag after reading `\n` and attach the timestamp to >>> the following message.* >>> >>> I am also following this approach for printing timestamp and >>> FT_COMPONENT. >>> Actually dlg uses a flag `dlg_features` in which different features >>> like `dlg_output_timestamp`(for timestamps) and `dlg_output_tags`(for >>> FT_COMPONENTS) are summed up using binary *OR *operator. >>> For the first log message, these flags are kept ON so that timestamp and >>> FT_COMPONENT values are printed, and for the next coming log messages the >>> following logic is used: >>> If the current log message contains a `\n` in it then the flags will be >>> toggled ON for the next coming log message assuming that it is end of a log >>> message, >>> and if the current log message doesn't contain `\n` then these flags are >>> toggled OFF for the next coming log message assuming that it is in >>> continuation of current log message. >>> >>> *> Also, I would believe that `fmt[strlen(fmt) - 1] == '\n'` is rather >>> fast, esp. given that this is followed by an IO operation. To be tested >>> though :)* >>> OK >>> >>> *> Writing this lead me to look for multi-linebreak traces (e.g. >>> src/pcf/pfcread.c:504) -- should that have one timestamp for the entire >>> statement or one timestamp per line?* >>> >>> With the above logic for these types of logs, there will be one >>> timestamp per line... >>> >>> Thanks, >>> Priyesh >>> >>> On Sun, Jul 12, 2020 at 2:02 PM <[email protected]> wrote: >>> >>>> > Since debugging isn't time critical it might be necessary to add an >>>> additional >>>> > step that scans tracing messages for newline characters, then >>>> massaging the >>>> > output by inserting the time stamp. In other words, all occurrences >>>> of >>>> > >>>> > `\n` >>>> > >>>> > should be replaced with >>>> > >>>> > `\n[time stamp] ` >>>> > >>>> > or something similar. >>>> >>>> This would print wrong-ish timestamps that couldn't really be used for >>>> profiling (I mean, it could; you just have to know which timestamp belongs >>>> to which message). I would suggest to rather store a flag after reading >>>> `\n` and attach the timestamp to the following message. Also, I would >>>> believe that `fmt[strlen(fmt) - 1] == '\n'` is rather fast, esp. given that >>>> this is followed by an IO operation. To be tested though :) >>>> >>>> Writing this lead me to look for multi-linebreak traces (e.g. >>>> src/pcf/pfcread.c:504) -- should that have one timestamp for the entire >>>> statement or one timestamp per line? >>>> >>>> Armin >>>> >>>>
With FT_LOGGING 0.102358 0.047597 0.046600 0.048298 0.044149 0.048377 0.048345 0.041690 0.042249 0.042481 With FT_DEBUG_LEVEL_TRACE: 0.095060 0.098922 0.103683 0.098869 0.103538 0.096481 0.101113 0.098012 0.096818 0.095626 No Debugging 0.020688 0.015904 0.015023 0.014677 0.014691 0.014862 0.020303 0.015747 0.016464 0.016172
