Microsoft Excel

Herbers Excel/VBA-Archiv

Bildschirmverzögerung


Betrifft: Bildschirmverzögerung von: Jan
Geschrieben am: 24.10.2017 18:59:22

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

  

Betrifft: warum denn Select, ist ScreenUpdating aus? owT von: Matthias L
Geschrieben am: 24.10.2017 19:06:27




  

Betrifft: AW: warum denn Select, ist ScreenUpdating aus? owT von: Jan
Geschrieben am: 24.10.2017 19:42:24

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...


  

Betrifft: AW: Bildschirmverzögerung von: onur
Geschrieben am: 24.10.2017 20:41:39

Kannst du die datei mal posten? Notfalls mit Dropbox-Link.


  

Betrifft: AW: Bildschirmverzögerung von: Jan
Geschrieben am: 24.10.2017 21:35:51

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


  

Betrifft: AW: Bildschirmverzögerung von: onur
Geschrieben am: 24.10.2017 21:38:13

Ohne die Datei wäre alles nur Raterei.


  

Betrifft: Windows hat öfters ... von: lupo1
Geschrieben am: 25.10.2017 05:00:24

... 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).


  

Betrifft: AW: Windows hat öfters ... von: Jan
Geschrieben am: 25.10.2017 08:17:41

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


  

Betrifft: Bei so großen Anwendungen ... von: lupo1
Geschrieben am: 25.10.2017 09:58:30

... (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.


  

Betrifft: AW: Bei so großen Anwendungen ... von: Jan
Geschrieben am: 25.10.2017 18:32:44

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


  

Betrifft: Evtl. downsizen auf Excel 2000 oder 2003 von: lupo1
Geschrieben am: 26.10.2017 06:40:54

... 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


  

Betrifft: AW: Evtl. downsizen auf Excel 2000 oder 2003 von: Jan
Geschrieben am: 26.10.2017 10:05:29

... 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...


  

Betrifft: "Dateigröße bei xls größer" ... von: lupo1
Geschrieben am: 26.10.2017 10:37:42

... 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.


  

Betrifft: AW: "Dateigröße bei xls größer" ... von: Jan
Geschrieben am: 26.10.2017 19:57:12

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


  

Betrifft: Teste es doch mal selbst von: lupo1
Geschrieben am: 27.10.2017 10:31:45

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.


  

Betrifft: AW: Teste es doch mal selbst von: Jan
Geschrieben am: 30.10.2017 12:23:01

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


  

Betrifft: Zwei Anmerkungen (ich bin so ungeschminkt) von: lupo1
Geschrieben am: 30.10.2017 13:01:34

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)


  

Betrifft: AW: Zwei Anmerkungen (ich bin so ungeschminkt) von: Jan
Geschrieben am: 05.11.2017 17:49:01

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