Re: [g-a-devel] At-spi2-atk performance tests



Hi again!

I've detected a problem into the last tests. If you look at the sysprof output files, you will detect that there is a library (libxapian) consuming a lot of cpu time, distorting the results (see /usr/lib/libxapian.so.22.3.0 cpu time).

Note (from the package):

"The Xapian search engine library is a highly adaptable toolkit which allows developers to easily add advanced indexing and search facilities to their own applications. It implements the probabilistic model of information retrieval, and provides facilities for performing ranked free-text searches, relevance feedback, phrase searching, boolean searching, stemming, and simultaneous update and searching. It is highly scalable, and is capable of working with collections containing hundreds of millions of documents."

This is due to a bug that occurred when migrating this library from a previous version of Ubuntu (but it's just solved). So, I had to upgrade my system to solve the bug and repeat the tests with the same parameters. Also, I've added the master branch results. I've tried also with master branch without the related commit, but it was not possible to compile the package.

Like the previous time, I send the results attached. If you look the report, you can see that valgrind results (memory consumption) are just as expected; but sysprof results (cpu time) are a bit different. As you can see in the charts, the results over the three branches are very similar.

In the nautilus case, we can see that the results don't improve, but they are the same or, even, the opposite. Also, in the last case (accesibility enable + orca running), I have had a problem to measure the difference, because, like in the libxapian case, orca consumption is high and distort the results. So, to can compare, I've had to add orca cpu time to the nautilus cpu time.

In the rhythmbox case, we can see that the result's improve a bit, but not as expected. That's because on the "before commit" branch, we can't see the problem we are trying to solve. There is a noticeable difference between the "accesibility enable" case and the "accesibility enable + orca" case. This should not be so before the commit, as far as I understand. But... results are results (I'm sure it is not a bug this time). Also, as in the nautilus case, I've had to add orca cpu time and also pulseaudio cpu time to can compare the results.

Now, to solve the orca consumption problem into the results, I'm doing new tests using a modified python script instead of orca. The first tests give good results, as far as I can see.

I hope to can send new results during the weekend.

Best regards,

                        Alejo.

Attachment: performance_v2_2.tar.gz
Description: GNU Zip compressed data



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]