| |
| |
|
| - page 1 - |
|
 | allô, alle zusammen!
j'ai ici plusieurs Fragen zur Geschwindigkeit de Profan² Programmen:
1.
j'ai chez mir sur dem gleichen calculateur zur Zeit quatre différent Betriebssysteme installiert (Pentium2, 233MHz - Windows3.1 / Windows95 / Windows98 / Windows2000). Dabei c'est moi aufgefallen, qui zumindestens qui Bitmap Befehle de Profan² sous den individuel Betriebssystemen avec (extrem) unterschiedlicher Geschwindigkeit abgearbeitet volonté (getestet avec Speicherbitmaps de 640x270 Pixeln Taille). sous Windows2000 scheint qui Testanwendung seulement avec einem drittel qui Geschwindigkeit comment sous Windows95 trop courir. sous XP scheint qui Geschwindigkeit sogar sur un zehntel trop schrumpfen! Hat quelqu'un ähnliche/autre Erfahrungen gemacht? peux sich quelqu'un cet extremen Unterschiede expliquer? rendez-vous cet Geschwindigkeitsunterschiede aussi sur autre Profan Befehle trop?
2.
si qui Punkt 1. überhaupt so zutrifft, comment sieht es ensuite avec qui Geschwindigkeit de anderen , pas dans Profan² erstellten Anwendungen bzw. den API`s aus, qui cela Gleiche 1faire?
3.
Programme sembler avec qui Profan² Version 6.0 doppelt so vite trop courir, comment avec Version 7.5 (jedenfall qui Bitmap Befehle). comment vite fonctionne XProfan² wirklich? Schneller comme 6.0 ou bien langsamer comme 7.5?
4.
j'ai dans mon Testprogramm LOADSIZEDBMP verwandt, um cela Testspielchen chez chacun Grafikauflösung toujours dans qui gleichen Taille darzustellen. Logisch wäre ici, qui sich qui Farbtiefe et qui Bildschirmauflösung très stark sur qui Geschwindigkeit auswirken. c'est mais définitif pas chez allen Rechnern so! comment peux on sich cela expliquer? Liegt cela eventuell am Grafiktreiber??
avec cela, qui je sous Umständen sur anderen Betriebssystemen avec Geschwindigkeitsverlust le calcul doit, habe je gerechnet. cet extremen Unterschiede (sous 1.) trop Windows2000/XP hin peux je mir avec meinem Erklärungsmodell alleine pas hinbiegen - c'est pourquoi ici nochmals mon sondage... |
|
| |
| |
| |
|
| |
| |
| - page 3 - |
|
|
| |
| |
| |
| |
|
|
| |
| |
| |
| |
|
|
| |
| |
| |
| |
|
|
| |
| |
| |
| |
|
|
| |
| |
| |
| |
|
|
Michael
Wodrich | Könnte on, zumindest chez den aufeinanderfolgenden Meldungen, peut-être. qui quelqu'un hat soeben abgestimmt pas sur une Eintrag réduire?
qui reporter schaut pour comment qui dernier Text (1.la ligne) est et si identique avec Jhsa(Kurzform) ensuite wird gelöscht et récente eingetragen (alors eigentlich seulement qui date/Zeit-Wert récente gesetzt).
belle Grüße
Michael Wodrich |
|
| |
| Programmieren, das spannendste Detektivspiel der Welt. | 09.06.2007 ▲ |
|
| |
|
|
 | oui c'est ca. qui reporter selber kanns pas - qui ist sturblöd un reiner Auftragsposter. mais je pourrait dem reporter beibringen dem Optimierer  une nouvelle trop hinterlassen cela un fil wohlmöglich optimiert volonté muss. qui Optimierer erkennt ensuite gleiche Postings de qui gleichen personne (ici qui reporter - ou bien qui De toute façon) et serait qui Doubletten entfernen. (si aussi nachträglich - quoi en supplément mener peux cela quelquefois pour kurze Zeit doch deux derartige Postings sichtbar wären).
ensuite devrait qui Optimierer seulement encore den Themencache aufbrechen et hieraus entsprechende Postings entfernen. (seulement aus DB effacer reicht pas) si qui Themencache modifiziert wurde pourrait qui Optimierer aussi juste encore qui gelöschten Postings aus den abgelegten Offlinethreads rausfummeln.
Spätestens si ensuite qui Tägliche Inhaltegenerator den Themenindex récente aufbaut sollte ensuite aussi dans den Inhaltsverzeichnissen cela aktualisierte Content disponible son sodass kurz puis hin qui Suchworteindizierungsbot sich dessen récente servir peux um wiederum den Suchindex trop optimaliser.
Ist mir arrêt aujourd'hui pas alles à einem journée gelungen. |
|
| |
| |
| |
|
|
| |
| |
| |
| |
|
|
| |
| |
| |
| |
|
|
| |
| |
| |
| |
|
|
| |
| |
| |
| |
|
|
| |
| |
| |
| |
|
(1.137)
Deutsch
English
Français
Español
Italia