[Kstars-devel] Binary star data loading accomplished in Branch!

[Jason Harris]

Hi,

On Jun 2, 2008, at 10:19 AM, Andrew Buck wrote:

>>> Another reason could be that these time tests were performed in a
>>> very coarse manner, where I started the two processes "together" (by
>>> putting one as sleep 10; ...branch.../kstars and the other as
>>> ..trunk.../kstars and then firing the second one ten seconds late).
>>> Probably somebody could do a more professional timing test which I
>>> don't know how to do.
>>
>> There is timing code in skymapevents.cpp that you can copy.  It looks
>> like this:
>>
>>   QTime t;
>>   t.start();
>>   ... do something ...
>>   kDebug() << QString("Something took %1 ms").arg(t.elapsed());
>
> Another possibiltiy is the unix "time" program.  You just run "time
> kstars" and when the program finishes execution it will spit out total
> runtime and a couple other numbers, see "man time" for details.
The problem with time is that it's so coarse...you only get the time  
it took to execute the entire program, not the time it took to execute  
a particular function.

Still, it might be worthwhile since the two codebases basically only  
differ in the star-loading code at this point.  Especially if you  
compared "time kstars --dump", so you wouldn't have to worry about  
differences in reaction time in killing the program.

> Another
> helpful trick is to profile the code.  Just edit the makefile to  
> include
> the -pg option to the compiler and linker and then build and run your
> program normally.  When it is done running there should be a file  
> called
> "gmon.out" located either in the current directory or in the directory
> where kstars is located, I think it will be the latter.  The gmon.out
> file can then be parsed by running "gprof kstars gmon.out | less"  
> which
> will tell you exactly what functions were called, how many times, how
> long they took, etc.  Just as a side note though, I have tried running
> this myself and have gotten some strange results with it, I think the
> way KStars is built creates some kind of issue with the profiling.   
> Does
> anyone know if there actually more than one binary file built or
> something like that?
>
I tried gprof at some point, but I like valgrind better for  
profiling.  KStars takes *forever* to run through valgrind, though.

Jason

> -Buck
>
> _______________________________________________
> Kstars-devel mailing list
> Kstars-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kstars-devel