Live-Forum - Die aktuellen Beiträge
Anzeige
Archiv - Navigation
1584to1588
Aktuelles Verzeichnis
Verzeichnis Index
Übersicht Verzeichnisse
Vorheriger Thread
Rückwärts Blättern
Nächster Thread
Vorwärts blättern
Anzeige
HERBERS
Excel-Forum (Archiv)
20+ Jahre Excel-Kompetenz: Von Anwendern, für Anwender
Inhaltsverzeichnis

Bildschirmverzögerung

Bildschirmverzögerung
24.10.2017 18:59:22
Jan
Hallo zusammen,
ich habe eine recht rechenintensive Datei mit mehr als 30 sheets und ca. 3 MB Größe. Zur Navigation habe ich ein paar Buttons mit select Anweisung hinterlegt. SW ist Office 365 Version 2016 mit 32bit.
Wenn ich die sheets via Button wechsle gibt es immer eine Bildschirmaufbauverzögerung. Sprich, an einer Stelle sehe ich den Bildschirmteil des vorherigen Bildschirms noch während der Rest schon aufgebaut ist bzw. den neuen Bildschirm darstellt. Switche ich durch direktes anklicken des Tabellenblattes in der Fußleiste habe ich diese Verzögerung nicht. Es macht keinen UNterschied, ob ich .select oder .activate nehme. Immer ist die Verzögerung da. Habe die gleiche Datei auf einem leistungsschwächeren Macbook Pro ausprobiert und es gibt keine Verzögerung beim Bildschirmaufbau.
Habt Ihr eine Idee wie ich die Verzögerung vermeiden kann?
Beste Grüsse,
jan

17
Beiträge zum Forumthread
Beiträge zu diesem Forumthread

Betreff
Datum
Anwender
Anzeige
warum denn Select, ist ScreenUpdating aus? owT
24.10.2017 19:06:27
Matthias
AW: warum denn Select, ist ScreenUpdating aus? owT
24.10.2017 19:42:24
Jan
Select/activate, um das jeweilige sheet anzusprechen - activeworkbook.worksheets(NAME).select
Bildschirmaktualisierung ist bei dieser einen code line nicht deaktiviert, da die einzige Aktion die Aktivierung ist. sonst würden aus einem Befehl drei (false - aktivierung - true). Habe es dennoch praktisch kurz probiert. Kein Unterschied.
Hintergrund der Verzögerung ist die Berechnung beim Umschalten (keine Verzögerung, wenn ich die Berechnung deaktiviere). Aber die Abschaltung ist keine Lösung, da ich nach die automatische Berechnung nach dem Wechsel des Tabellenblattes wieder zuschalten muss.
Ich bin erstaunt, dass es auf dem schwächeren mac nicht passiert. genausowenig wie beim direkten Wechsel via Blattregister...
Anzeige
AW: Bildschirmverzögerung
24.10.2017 20:41:39
onur
Kannst du die datei mal posten? Notfalls mit Dropbox-Link.
AW: Bildschirmverzögerung
24.10.2017 21:35:51
Jan
Hi Onur,
Leider bei dieser Datei nein. kriege ich Ärger mit meinen Mitgesellschaftern. Die Datei geht bspw. auch nur an Vertragskunden nachdem sie durch den compiler gelaufen ist. Sorry, hoffe Ihr könnt dennoch helfen. Insbesondere, dass es beim Mac und via Blattregister kein delay gibt macht mich zuversichtlich, dass es eine Einstellungs- o.ä. Frage ist.
BG,
Jan
AW: Bildschirmverzögerung
24.10.2017 21:38:13
onur
Ohne die Datei wäre alles nur Raterei.
Windows hat öfters ...
25.10.2017 05:00:24
lupo1
... fehlerhafte (oder sogar absichtlich nicht vollkommen durchgeführte) Bildschirmaktualisierungen. Mag sein, dass Mac-IOS (oder wie das Apple-Ding heißt) sauberer implementiert ist.
.Select und .Activate deuten auf schwere Programmierschwächen Deinerseits hin. .ScreenUpdating braucht man nicht, wenn man mit Zuweisungen und Programmkonzepten wie Variants, Collections oder Dictionaries arbeitet, statt "den Cursor Gassi zu führen" (Hajo).
Anzeige
AW: Windows hat öfters ...
25.10.2017 08:17:41
Jan
Hi Lupo,
danke für Dein feedback. Merkwürdiges Windowsverhalten und das Warum etwaiger absichtlicher Fehler erschliesst sich nicht wirklich. Das Ding heißt OSX ;-))
Aber zu den "schweren Programmierschwächen" - wir nutzen innerhalb der Programmstrukturen nirgends .select oder activate, sondern u.a. die von Dir genannten Optionen. Hier aber spreche ich vom "Bewegen" innerhalb der Datei, um es dem Endnutzer komfortabel zu machen, von einem sheet zum anderen zu navigieren. M.E. geht es in diesem Fall wohl nur mit dem von Dir zitierten "Cursor Gassi gehen", da ein Wechsel der Bildschirmansicht gewollt ist. Kennst Du einen anderen Weg für diesen Zweck?
BG,
Jan
Anzeige
Bei so großen Anwendungen ...
25.10.2017 09:58:30
lupo1
... (habe ich noch nie benötigt) sollte man vermutlich noch mehr beachten:
- keine Formeln, und Zellen werden allein durch VBA-Subs befüllt. Vorteil: Du kannst bis ins Kleinste die Geschwindigkeit optimieren, indem Du tatsächlich jeweils nur das berechnest, was berechnet werden muss.
- vermutlich würde ich auch nicht mit Sheets arbeiten, sondern nur mit einem einzigen variablen Ausgabe-Arbeitsblatt, welches mir die Informationen im Wechsel anders anzeigt. Daten- und Parameter-Arbeitsblätter gäbe es natürlich weiterhin. Die Daten wären aber normalisiert organisiert.
AW: Bei so großen Anwendungen ...
25.10.2017 18:32:44
Jan
Hi Lupo1,
da hast Du vom Grundsatz her sicher recht, aber - hilft zwar nicht der Frage, aber vielleicht dem Verständnis - aber es handelt sich um ein integriertes Financial Modell, welches GuV, Bilanz und Liquidität rückwirkend und nach vorn abhängig miteinander verknüpft. Alle Berechnungsschritte zur Darstellung des Status Quo befinden sich in vorgelagerten Modulen und Dateien und werden bereits als Festwerte zur Minimierung des Rechenaufwandes im Modell eingelesen.
Die noch im Modell verbliebenen notwendigen Berechnungen beziehen sich ausschliesslich auf simulative Eingaben des users. Und durch die o.g. Kombi mit ihren Abhängigkeiten ist es selbst nur für die Simulationen mit noch immer ca. 150.000 Formeln wovon 10.000 tatsächlich "distinct" sind ein anspruchsvolles Unterfangen. Diese aktuell 10.000 Formeln mit VBA Subs zu berechnen ist mir für Erstprogrammierung und Pflege/Adaption zu aufwendig.
Bei den Ausgabesheets sprechen wir von mehr als 25 vollkommen verschiedenen simulierbaren "Bildschirmen". Die zu alignen ist w/der Differenziertheit nicht sinnvoll/möglich.
Ich würde gern weitere Berechnungen auslagern, aber dies ist w/der Abhängigkeiten nicht möglich bzw. zu umständlich. Das Modell ist grundsätzlich auch schnell und reagibel genug, aber der manchmal verzögerte Bildschirmaufbau in Windows nervt und ist auch nicht wirklich nachvollziehbar.
Insofern - wer noch eine Idee hat ;-))
BG,
Jan
Anzeige
Evtl. downsizen auf Excel 2000 oder 2003
26.10.2017 06:40:54
lupo1
... manchmal bringt das etwas. Am ehesten weh tut eigentlich nur der Verzicht auf WENNFEHLER. Mehr als 65000 Zeilen wirst Du ja auch nicht haben.
Die alten Programme waren im Kern 22 Jahre lang unverändert (von 1994-2006). Mit xl2007 wurde alles (oder vieles) neu.
Achtung: xl2000 läuft nur bis Win 7. Ich habe es unter 8, 8.1 oder 10 nicht hinbekommen. Allerdings könnte man das evtl. mit einem alten Win XP in einer virtuellen Umgebung dort erreichen.
xl2000 (evtl. mit xl1997) ist sowieso das beste Excel jemals überhaupt, da es einen beeinflussbaren Abhängigkeitsbaum hat: http://xxcl.de/foreign/excelstuff.htm
Anzeige
AW: Evtl. downsizen auf Excel 2000 oder 2003
26.10.2017 10:05:29
Jan
... tried but failed. Dateigröße stieg um Faktor 3 und Verhalten beim Bildschirmaufbau wie vorher. Wäre eh keine nachhaltige Lösung, da (a) Kunden die alte Infrastruktur befremdlich finden würden und (b) das System auch nach vorn funktionieren muss (auch wenn MS irgendwann das coverage einstellt). Aber dennoch - danke fürs weiter mit denken.
Im Grundsatz hast Du recht- habe in den letzten Jahren auch bemerkt, das die neueren Versionen immer instabiler wurden. Oder nimm die "alten" XL4 Makros, die ich mangels Substitut in der "neuen" VBA Umgebung weiter nutze. so lange das noch geht...
Anzeige
"Dateigröße bei xls größer" ...
26.10.2017 10:37:42
lupo1
... stimmt nur für Speicherung auf Medien, nicht für Hauptspeicherbelegung. Die ist gleich. Übrigens machen die Werte bei .xlsx mehr Speicherplatz aus, als die Formeln. Daher könnte es sich, egal bei welcher Version, lohnen, die Formeln erst nach Öffnen der Datei automatisch überhaupt erst zu erstellen. Und vor dem Speichern zu entfernen (und nicht nur die Werte beizubehalten).
"Befremdlich wegen veraltet" ist ein zulässiges Argument. Weder werden die Kunden alte Prg installiert haben, noch dieses heute noch können.
Bleibt halt nur, dass ein Bildschirmflackern oder falsche Wiedergabe nur durch andere Programmierung zu beseitigen wäre.
Anzeige
AW: "Dateigröße bei xls größer" ...
26.10.2017 19:57:12
Jan
Hi Lupo1,
interessant, Dein Hinweis re/Kapazitätshunger Formeln vs Werte. Du meinst sicher (Festplatten)speicher und damit nicht performancerelevant, oder?
Kannst Du noch etwas erläutern, was Du mit beim Öffnen Formeln erstellen und beim Schliessen Formeln wieder löschen meinst und wo Deiner Ansicht nach der Vorteil dieser Aktion wäre? Und meinst Du mit Erstellen tatsächlich 150k Formeln per Prozedur zu erstellen?
J
Teste es doch mal selbst
27.10.2017 10:31:45
lupo1
1. Fülle Spalte A mit =ZUFALLSZAHL(). Speichere. Gucke Dateigröße.
2. Öffne neu. Mache die Formel platt (das ist mein Begriff für "kopiere ihre Werte über sie"). Speichere. Dateigröße.
Und das zunächst für .XLSX und dann für .XLS.
Bei .XLSX siehst Du als Ergebnis, dass die verbleibenden Werte viel mehr reinhauen (16 Byte pro Zelle = Variant), als die vorher noch vorhandene sich wiederholende Formel. Bei .XLS wird die Formelwiederholung zumindest nicht so ausgeprägt berücksichtigt. mMn ist das auch nicht notwendigerweise eine Angelegenheit des .ZIP-Formats von .XLSX.
[B1:B150000] = "=Nicht-Lokale_Formel_im_R1C1_Format"
ist die einzige notwendige Anweisung im Workbook-Open, um die Formel wieder auszubreiten. Du kannst sogar auf .FormulaR1C1 verzichten, da Excel (xl2010) das selbst rafft. Beim Datei-Schließen bzw. Speichern vor dem Schließen-Ereignis kannst Du entsprechend
[B1:B150000].Clear oder
[B1:B150000].ClearContents
vorsehen.
Anzeige
AW: Teste es doch mal selbst
30.10.2017 12:23:01
Jan
Hi Lupo1,
sorry für die Pause. Habe Deinen Test grad durchlaufen lassen. Bei der Einspaltenlogik(1 Spalte mit 15.000 Zeilen) hatte ich Werte von (i) Formelversion 350kb und (ii) Werteversion 279kb. Also ist bei mir die Formelversion ca. 25% größer...
Wollte dann noch rausfinden, welchen Performanceunterschied beim Öffnen es macht und habe beide Versionen mit 1.000 Spalten mal 15.000 Zeilen erzeugt. Dateigrößen bei (i) 293MB und (ii) 210MB, also ca. 40 Prozent Größenunterschied. Wie erwartet beim Öffnen deutlich größeres Delta: (i) 34sec und (ii) 17sec, i.e. Faktor 2...
Zum Erzeugen der Formeln via Sub - wenn Du nur "gleiche Formeln" sicher ein machbarer Weg. Bei 10.000 verschiedenen allerdings müsstest Du ja jede dieser Formeln einzeln erzeugen lassen.
BG,
Jan
Anzeige
Zwei Anmerkungen (ich bin so ungeschminkt)
30.10.2017 13:01:34
lupo1
1) Wer 10.000 verschiedene Formeln hat (statt gleiche mit verschiedenen Parametern versorgte Formeln), tut mir leid. Das wirst Du mir nicht im Ernst weismachen wollen. Formeln sind gleich, wenn sie in R1C1-Schreibweise gleich sind.
2) Beim Test
a) Formeln mit Werten und
b) Nur Werte fehlt noch
c) keines von beiden, Formeln zur Laufzeit.
Denn meine Behauptung war doch (jetzt abgestimmt auf Dein Ergebnis):
Von a) zu b) 25% Verschlankung, aber
von b) zu c) eine in Byte noch größere Verbesserung (war vielleicht missverständlich oder vergessen)
AW: Zwei Anmerkungen (ich bin so ungeschminkt)
05.11.2017 17:49:01
Jan
Danke für Dein Mitleid ;-))
Ist wie beschrieben ein komplexes Financial Model mit 150.000 Formeln, davon 6.000 "distinct". Sprich mehr als 95% sind wie von Dir beschrieben identisch mit lediglich verschiedenen Parametern (Zeit, Frequenz, underlying etc.), aber doch einige Tausend vollkommen unterschiedlich. Das vorgelagerte (zugehörige) Modul hat noch einmal ca. 5.000 "distinct" Formeln. Lässt sich bei der abgebildeten Komplexität und Umfang auch nicht vermeiden ...
BG,
jan

Beliebteste Forumthreads (12 Monate)

Anzeige

Beliebteste Forumthreads (12 Monate)

Anzeige
Anzeige
Anzeige