commonqt-devel December 2010

commonqt-devel@common-lisp.net

2 participants
3 discussions

[commonqt-devel] Microbenchmarks
by David Lichteblau 26 Dec '10

26 Dec '10

Hi, I've added the existing microbenchmark code to the "test" directory of the repository, and cleaned it up a little. (This infrastructure is best benchmark operations in the microsecond to millisecond range. Real-world "macrobenchmarks" should probably be done differently.) The instructions are at the top: ;;;; Evaluate ;;;; (qt::microbench) ;;;; to run these benchmarks on an otherwise idle computer. Results are ;;;; written to the REPL, and in a machine readable format also dribbled ;;;; to files. Files names are, by default, of the form <lisp ;;;; implementation type>.txt. ;;;; ;;;; Notes: ;;;; 1. These are microbenchmarks meant to aid understanding of the ;;;; implementation. They do not necessarily reflect overall or ;;;; real-world performance. ;;;; 2. Since each individual operation is too fast to benchmark, we ;;;; invoke them a large number of times and compute the average run ;;;; time afterwards. ;;;; 3. Before running benchmarks, we choose a repetition time depending ;;;; on how fast (or slow) a simple test case is, so that slow Lisps ;;;; don't waste endless time running benchmarks. ;;;; 4. Benchmarks are run three times, and only the best run of those ;;;; three is reported, to account for issues with background activity ;;;; on the computer ruining the results. ;;;; 5. But you should _still_ run the overall benchmarks several times ;;;; and see how reproducible the numbers are. ;;;; ;;;; There's no tool to parse the output files and drawn graphs yet, but ;;;; there should be. (READ-MICROBENCH-RESULTS already fetches the raw ;;;; sexps from each file though, just to check that they are READable). d.

1 0

[commonqt-devel] Tests and minor changes to :override
by David Lichteblau 26 Dec '10

26 Dec '10

Hi, I have just pushed minor changes and tests for the method overriding syntax. - Added a first test case checking that :override works at all. - Fix function spec parsing to signal an error on invalid specs. - Extend function spec parsing to macroexpand the form. Test changes seem harmless enough that I've pushed them directly to the main repo, but just in case the usual request: Please test! d.

1 0

[commonqt-devel] recent commonqt changes
by Ivan Shvedunov 26 Dec '10

26 Dec '10

Dear colleagues, I've pushed the changes I've accumulated over the last week to my github repository ( https://github.com/ivan4th/commonqt/ ). Please review them and let me know whether I should push some of them to the main repo. Some comments. 1. I've fixed OUTPUT-FILES method on CPP->SO in qt.asd. Without this change, commonqt was being reloaded every time, at least when loading it via quicklisp, due to problems with FASL relocations. Also, SWANK:DELETE-SYSTEM-FILES was deleting only commonqt.so which didn't get restored by make during compilation. 2. When unparseable signal/slot signature was encountered, a rather mysteriously looking error was displayed. I've added a check to MAKE-SLOT-OR-SIGNAL with more readable error message. 3. To make QTYPEP more useful outside CommonQt's own code I've made it recognize type argument specified as string (integer values are still accepted of course). 4. I've added more QVariant conversions to qvariant.lisp. It's still doesn't support all necessary types but at least now it's possible to colorize and decorate these Q*Views. 5. UNMARSHALLER now caches unmarshalled closures. This seems to improve performance a bit in %METHOD-INVOCATION-CALLBACK as it doesn't cache anything itself. Also, I've got rid of redundant NONCONST-NAME function I've introduced previously. I did some tests on a QListView code with custom model with SBCL statistical profiler and seems like all this indeed helps (will later distill that test code into automatic benchmark). 6. The most recent commit is an attempt to cache marshaller closures too, which didn't succeed so far (perhaps I've did something silly there). If you enable cached version of MARSHALLER CommonQt crashes pretty soon when method invocation callbacks happen. This commit shouldn't be pushed to the main repository yet of course. I've tried to research problems with Qt Hemlock. On my machine it causes memory fault soon after (hi::hemlock) on (#_show window) in HI::%INIT-SCREEN-MANAGER. After some debugging with gdb attached to SBCL I've managed to get stack trace of the problem (see attached file). If you google for "QVector<QPair<double, QVariant> >::end" you'll see that the problem is not unique. It happens somewhere in Qt intestines in animation fx related code. Seems like QPropertyAnimation object (it's also QVariantAnimation and QAbstractAnimation) gets destroyed to early. I doubt this problem is directly related to CommonQt changes and most likely it's a bug in Qt which gets triggered by current stack state and other random reasons. I will research it further in coming days. -- Ivan Shvedunov <ivan4th(a)gmail.com> ;; My GPG fingerprint is: 2E61 0748 8E12 BB1A 5AB9 F7D0 613E C0F8 0BC5 2807

2 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commonqt-devel December 2010