|
|
|
|
|
|
|
Qbs vs. rekursives make
Projektstruktur:
- 5 Subprojekte
- 3 davon Bibliotheken
- 2 davon hängen von den Bibliotheken ab
- make/qbs: identische Projektkonfiguration, identische Linkage
- Makefiles von qmake erzeugt
clean -> make all:
rekursives make -j6: 32 Sekunden
qbs: 22.7 Sekunden
-29 % Buildzeit
1 Bibliotheksimpl. geändert -> make
(impliziert kompilieren von einer Sourcefile und neulinken der beiden Anwendungstargets)
rekursives make -j6: 6 Sekunden
qbs: 2.9 Sekunden
-52 % Buildzeit
Krass. Ich hätten nicht gedacht, dass das so einen Unterschied macht, gerade weil beide Buildsysteme in dieser Situation das exakt gleiche tun in Hinsicht auf was kompiliert wird etc.
Der Geschwindigkeitsunterschied kommt also allein durch Overhead im Buildsystem zustande.
Bonuspunkte für Qbs ggü. qmake: Einfachere Dateien, gefühlt besser dokumentiert
Abzüge für Qbs ggü. qmake: Einrichtung aufwendiger, z.B. muss man nach der Installation erstmal ein paar Befehle aus der Doku ausführen ; scheint in Distros kaum gepackaged zu werden.
Oh, und im Gegensatz zu rekursivem Make muss man nicht selber nachdenken, in welcher Reihenfolge Subprojekte gebaut werden müssen.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 14.09.2014 14:30]
|
|
|
|
|
|
|
|
|
|
Was meinst du genau mit "nachdenken, in welcher Reihenfolge Subprojekte gebaut werden müssen"? Sollte man sowas nicht auch mit entsprechenden Abhängigkeiten ausdrücken können?
|
|
|
|
|
|
|
|
|
|
|
Schon, ja.
Aber das ist ja auch nur eine der Stolperfallen von rekursiven Make. Siehe recursive make considered harmful...
(Heck, manchmal merken sogar von CMake generierte Makefiles nicht, dass sie was tun müssen!)
/e: Aber ganz ehrlich, wenn ich 100 % schnellere inkrementelle Builds quasi für umsonst kriege... dann greife ich da doch zu.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 14.09.2014 15:55]
|
|
|
|
|
|
|
|
|
https://bugzilla.mozilla.org/show_bug.cgi?id=842623
| | | This is strictly a guess, but after seeing this a couple of different times for Wireshark and doing a bit of digging, it seems that the time/memory taken is proportional to the size of the file being diffed (not the size of the diff). For normal files it doesn't really show up, but when the file is many lines then the diff page can take minutes to load. | |
Und ich wundere mich, wieso sich Firefox ständig bei nem 10 Zeilen diff aufhängt. Die gediffte Datei hat >200 kB.
Dinge die besser der Server erledigt hätte: ..., große Diffs machen, ...
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 14.09.2014 17:02]
|
|
|
|
|
|
|
|
|
Dann mal gleich mein Erfahrungen dazu:
Syntax-Highlighting mit JavaScript durch den Browser sollen ja den Server schonen. Totaler Quatsch! Der Server muss das genau einmal machen und dann nie wieder. Das JavaScript-Engine im Browser muss die diversen Libraries erstmal laden und ausfuehren, letzteres bei jedem Aufruf. Der Nutzer hat nur sehr schnell die Nase voll, von der lahmen Website.
GUI aufgeteilt zwischen Server und Client, realisiert per JavaScript. Wo trifft man auf diesen epischen Fail? Google-Web-Toolkit und Vaadin, eine einzige Katastrophe. Nicht mal auf deren eigener Website funktioniert die Auto-Completion. Den Server haben die Vorgaeng beim Client bis zum Absenden einfach nicht zu interessieren.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 14.09.2014 18:51]
|
|
|
|
|
|
|
|
|
| | Zitat von krautjork
| | Zitat von Oli
Nutzt hier jemand Wordpress? Mein Blog ist derzeit eine Eigenentwicklung mit Python. Sollte ich das lieber aufpolieren oder auf WP wechseln? Was schätzt ihr unsicherer ein? 
| |
Dein Blog gefällt mir sehr gut, würde ich behalten und aufpolieren. Hatte dich auch schonmal hier im Thread gefragt was das ist, aber nie Antwort erhalten. 
| |
Danke. Ich muss das überlesen haben - habe gestern mal ein bisschen dran gearbeitet und setze poliere es demnächst noch weiter auf. Dann kommt der Code auf Github. Ist ne Eigenentwicklung basierend auf django, bestehend aus "blog", "tags", "files", "gallery" apps.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Most vexing feature of all time: Okular -> view -> trim margins.
Wieso verändert sich denn gar nix, wenn ich andere Ränder in Latex einstelle?!
|
|
|
|
|
|
|
|
|
|
|
Boah ey, versuche mich gerade an django migrations. Ich habe ein custom field, welches intern ein zweites Datenbank Feld managed für einen Cache. Bis ich mich da jetzt durchgewurstelt habe, wie man das dem Migrations Framework beibringt, habe ich die ganze Anwendung neu geschrieben und meine Daten per raw SQL statements zwischen den beiden Datenbanken migriert.
Da stimmt ein bisschen die häufige Kritik, dass django nur solange einfach ist, wie man nicht speziellere Usecases hat. (Nicht, dass es ein anderes Migrations framework gäbe, was das einfacher macht.)
|
|
|
|
|
|
|
|
|
|
|
Du kannst die Migration per Hand schreiben 
|
|
|
|
|
|
|
|
|
|
|
|
Das Kommando failed, wenn ich mein custom field nicht darauf vorbereite...
|
|
|
|
|
|
|
|
|
|
|
http://www.ics.com/portfolio#cruiseship sieht aus wie in einem Film oder PC-Spiel. Daneben gibts auch eine Drohnen-UI, die sieht aus wie in CoD... D: mit schematischer Minimap unten rechts!
... wat
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 16.09.2014 0:23]
|
|
|
|
|
|
|
|
|
|
nicht ohne Grund gibt's angeblich auch Xbox Gamepads als Input für die Drohnensteuerung. Das kennt der GI halt.
|
|
|
|
|
|
|
|
|
|
|
Naja die UI Entwicklung für solche Systeme ist der Realität halt quasi 10 Jahre voraus... Da muss man halt bei Battlefield kopieren
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
probier mal dein Material als Template hinzuschicken, dann kannst du das immer wieder verwenden.
|
|
|
|
|
|
|
|
|
|
|
|
läuft Netflix auf Liux oder brauch ich pipelight oder so nen Mist dafür?
|
|
|
|
|
|
|
|
|
|
|
|
pipelight. Alternativ geht glaube ich auch Chrome mit geändertem User-Agent.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Just don't go down 4 sub-shells, it's pure code fragments down there and you may never come back if your program crashes while you're that deep.
--
Speicherleck in Qt. Der Fix: 1 Zeile. Der Test: 10 Zeilen. Der Diff: >9000
(Disclaimer: Link braucht ein paar Sekunden zum Laden)
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 16.09.2014 10:39]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Triple Post. Glückwunsch!
|
|
|
|
|
|
|
|
|
|
|
Auch von meiner Seite, zur Aufheiterung ein Nugget:
| |
<grsecurity> Lennart's response to systemd bug report on grsec kernel: "use a supported kernel".
<grsecurity> His response when it's pointed out that the same feature exists upstream: "we don't support the kernel" https://bugs.freedesktop.org/show_bug.cgi?id=65575#c8
<grsecurity> Funny that it's "not compatible with how operating systems work these days" but worked fine for a decade and a half before he came along...
| |
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von RichterSkala
läuft Netflix auf Liux oder brauch ich pipelight oder so nen Mist dafür?
| |
laut heise.de forum gehst wie schon erwähnt mit nem aktuellen chrome und anderem useragent...
|
|
|
|
|
|
|
|
|
|
|
usb festplatten, die plage jeden datentransfers.
es geht einfach immer langsamer.
das ist echt eine schande, dass sich firewire damals nicht durchgesetzt hat. damit hatte ich nie diese art von problemen. das ist einfach kontinuierlich schnell, egal wo und womit.
|
|
|
|
|
|
|
|
|
|
|
|
USB 3.0 bei mir auch. USB 2.0 ist halt einfach scheiße, von den theoretischen 480Mbit bleibt ja in der Praxis nichts übrig.
|
|
|
|
|
|
|
|
|
|
|
das ist eine usb 3 platte, an einem usb 3 controller. sie schafft gerade unglaublich schnelle 500 KB/s.
btw. zieh ich die maus raus, dann hab ich knapp 200 KB/s mehr an bandbreite zur platte.
|
|
|
|
|
|
|
|
|
|
|
|
Hab neulich ~75MB/s mit einer WD Passport Trallala bei 40GB Transfer erzielt. Und ja, ein sync(1) ist fast sofort wieder zurückgekommen.</Productplacement>
|
|
|
|
|
|
|
|
|
|
|
|
Ich hab mit USB3 auch ganz gute Transferraten. 70-80 MB/s sind da schon die Regel.
|
|
|
|
|
|
|
|
|
|
|
Meine Toshiba STOR.E Basics 1TB macht auch 90-120MB sequentiell.
|
|
|
|
|
|
|
|
| Thema: 100 gute Gründe für Linux ( Gute Informatiker für ++30 ) |
