Hallo, per COM (VBA oder .NET) automatisiere ich zwei Programme. Aus dem einen Programm exportiere ich 100te Dateien, die in dem anderen Programm wieder eingelesen werden. Diese Dateien werden im temporären Ordner zwischengespeichert. Der Umweg über die Festplatte dauert unnötig lange. Ist es möglich die Dateien im RAM anstatt auf der Festplatte zwischenzuspeichern? Da meine SW auf Fremdrechnern installiert wird sollte das möglichst mit Bordmitteln gehen.
Prinzipiell sollte sowas nicht gehen weil das eine riesen Sicherheitslücke wäre wenn ein Programm einfach auf die Daten von einem anderen zugreifen könnte. Wenn beide Programm mitspielen gibt es eine paar spezielle API-Funktionen mit denen man sowas bauen kann: https://docs.microsoft.com/de-de/windows/win32/memory/creating-named-shared-memory
Thomas_jhfd schrieb: > Hallo, > > per COM (VBA oder .NET) automatisiere ich zwei Programme. > Aus dem einen Programm exportiere ich 100te Dateien, die in dem anderen > Programm wieder eingelesen werden. > Diese Dateien werden im temporären Ordner zwischengespeichert. > Der Umweg über die Festplatte dauert unnötig lange. > > Ist es möglich die Dateien im RAM anstatt auf der Festplatte > zwischenzuspeichern? > Da meine SW auf Fremdrechnern installiert wird sollte das möglichst mit > Bordmitteln gehen. Was bedeutet in diesem Fall per COM automatisieren zwei Programme? Entweder kommunizieren sie miteinander oder nicht. Die Frage kann auch so lauten - nicht Daten im Speicher zu haben, sondern was kann das zweite Programm, was das erste nicht kann oder umgekehrt? Wenn die Festplatte durch SSD ersetzt wird, dann kann es sein, dass die Performance steigen könnte. Die Lebensdauer der Festplatte aber nicht.
Ein "Programm" läuft in einem Prozess. Bei einem anständigen Betriebssystem haben zwei Prozesse zwei verschiedene Adressräume für den Speicher. Sie können sich also gegenseitig Speicherbereiche nicht lesen oder schreiben. ein paar Begriffe für Google: * Ramdisk (hatten wir schon) * TCP und 127.0.0.1 * IPC
Klar, eine Ramdisk wäre das Mittel der Wahl. Geht aber anscheinend nur mit externen Tools. Schade dass Windows von Haus aus keine Möglichkeit bietet. Shared Memory nutzt mir nichts, weil ich ja die Export Funktion von dem einen Programm, und die Import Funktion des anderen Programms fernbediene. Und das geht nun mal nur über das Dateisystem. TCP und 127.0.0.1 wäre dann eine Möglichkeit, wenn ich ein Netzwerklaufwerk im RAM einrichten könnte.
Thomas_jhfd schrieb: > Shared Memory nutzt mir nichts, weil ich ja die Export Funktion von dem > einen Programm, und die Import Funktion des anderen Programms > fernbediene. hä?
MaWin schrieb: > Thomas_jhfd schrieb: >> Shared Memory nutzt mir nichts, weil ich ja die Export Funktion von dem >> einen Programm, und die Import Funktion des anderen Programms >> fernbediene. > > hä? Was meinst du mit "hä?"? Wie würdest du einem Programm sagen, dass es die Dateien statt auf die Festplatte in einen Shared Memory schreiben soll? Und wie kommt überhaupt ein Dateisystem in den Shared Memory? Wohl gemerkt alles mit Bordmitteln.
> Aus dem einen Programm exportiere ich 100te Dateien, die in dem anderen > Programm wieder eingelesen werden. Das heißt, du hast irgendwas mit Windows-Bordmitteln zusammengebastelt. Jetzt wäre eine gute Zeit mal über eine anständige Architektur nachzudenken.
Thomas_jhfd schrieb: > Ist es möglich die Dateien im RAM anstatt auf der Festplatte > zwischenzuspeichern? Wenn du unter Linux Dateien speicherst und kurz danach wieder lädst, werden sie automatisch im RAM gepuffert. Ist das bei Windows etwa anders?
Rolf M. schrieb: > Und wie kommt überhaupt ein Dateisystem in den Shared Memory? Wozu das denn? Du hast nichts verstanden, daher auch das "hä". Selbstverständlich musst du halbwegs wissen was du tust wenn du eine Interprozesskommunikation programmieren willst. Übrigens heisst Shared memory, Überraschung, deshalb so weil Memory von beiden Prozessen benutzt werden kann. Was da drinsteht ist Sache des Programmierers. Georg
Rolf M. schrieb: > Wie würdest du einem Programm sagen, dass es > die Dateien statt auf die Festplatte in einen Shared Memory schreiben > soll? Indem ich das Programm entsprechend schreibe?
Georg schrieb: > Shared memory Ramdisk und shared memory würde ich vermeiden weil man nie weiß ob überhaupt genügend RAM in der Maschine ist. Wahrscheinlich braucht der To Thomas mal ein paar neue SSDs statt seiner müden Festplatten. Das würde einen wesentlichen Geschwindigkeitsgewinn bringen, da die magnetischen Festplatten das langsamste Teil im PC sind.
oszi40 schrieb: > Ramdisk und shared memory würde ich vermeiden weil man nie weiß ob > überhaupt genügend RAM in der Maschine ist. Kommt halt auf die benötigte Menge an.
Thomas_jhfd schrieb: > Der Umweg über die Festplatte dauert unnötig lange. Wenn vorgegeben wird, dass es übers Filesystem gehen muss, weil das Programm eben so arbeitet, keine SSD vorausgesetzt werden kann und Systemerweiterungen nicht notwendig sein dürfen, dann geht eben nur das, was das Betriebssystem mitbringt. Und ein RAM-Filesystem gibts m.W. in Windows nicht mit Bordmitteln (in Linux wird das heute in den üblichen Distros bereits von vorneherein eingesetzt).
Und sonst? schrieb: >> Aus dem einen Programm exportiere ich 100te Dateien, die in dem > anderen >> Programm wieder eingelesen werden. > > Das heißt, du hast irgendwas mit Windows-Bordmitteln zusammengebastelt. > Jetzt wäre eine gute Zeit mal über eine anständige Architektur > nachzudenken. Hier checken es wieder einige nicht, oder? Er hat eine Fremd Applikation die er über COM automatisieren kann, das automatisierte Programm bietet nur diese Schnittstelle mit Dateiausgabe, er kann daran nichts ändern, hat nichts mit seinem Code zu tun
cppbert3 schrieb: > Hier checken es wieder einige nicht, oder? Tja. Dann hätte Thomas_jhfd das halt mal so beschreiben sollen. Hellsehen kann ich leider nicht.
cppbert3 schrieb: > hat nichts mit seinem Code zu tun Wahrscheinlich gibt es so etwas wie "sein Code" einfach nicht. Georg
MaWin schrieb: > Tja. Dann hätte Thomas_jhfd das halt mal so beschreiben sollen. Hat er doch. Thomas_jhfd schrieb: > per COM (VBA oder .NET) automatisiere ich zwei Programme. Das COM für viele in einem Mikrocontroller-Forum halt RS232 bedeutet, hätte er berücksichtigen können. foobar schrieb: > Sicher, dass es die Platte und nicht das COM-Geraffel ist? Klär das erstmal ab. Bis Word per COM einen Dreizeiler geschrieben hat, kann man direkt Hunderte DAteien schreiben
Thomas_jhfd schrieb: > chade dass Windows von Haus aus keine Möglichkeit bietet. Also, wenn man ein ISO-Image öffnet, legt Windows automatisch eine virtuelle Partition an. Also existiert sowas doch in Windows. Man muß es nur programmtechnisch ansprechen und verwalten können.
Georg schrieb: > Rolf M. schrieb: >> Und wie kommt überhaupt ein Dateisystem in den Shared Memory? > > Wozu das denn? Du hast nichts verstanden, daher auch das "hä". Bist du dir da sicher? Ich glaube eher, du hast nichts verstanden, genauso wie der Autor des "hä". > Selbstverständlich musst du halbwegs wissen was du tust wenn du eine > Interprozesskommunikation programmieren willst. Die hat nur nichts mit den Dateien zu tun. Die IPC dient hier nur zur Fernsteuerung, nicht zur Übertragung der Daten. MaWin schrieb: > Rolf M. schrieb: >> Wie würdest du einem Programm sagen, dass es >> die Dateien statt auf die Festplatte in einen Shared Memory schreiben >> soll? > > Indem ich das Programm entsprechend schreibe? "Das Programm" hat er doch gar nicht geschrieben, sondern nur dessen Fernsteuerung. Er hat also ein fertiges Programm, dem er per IPC sagen kann, dass es eine Datei erstellen und auf der Platte speichern soll. Und wie soll er da bitte dieses Programm dazu bringen, diese Datei statt der Platte in einen Shared Memory zu legen? Wie schon von ihm erkannt, wäre eine Ramdisk dafür das Mittel der Wahl. Darin kann man im Gegensatz zu shared memory nämlich einfach Dateien anlegen, genau wie auf der Festplatte. MaWin schrieb: > cppbert3 schrieb: >> Hier checken es wieder einige nicht, oder? > > Tja. Dann hätte Thomas_jhfd das halt mal so beschreiben sollen. > Hellsehen kann ich leider nicht. Ich sehe nicht, wo er etwas anderes beschrieben hätte. Er schrieb: Thomas_jhfd schrieb: > per COM (VBA oder .NET) automatisiere ich zwei Programme. und nirgends hat er behauptet, dass er diese zwei Programme selbst geschrieben hätte. Was er aber erklärt hat, ist dass das eine Programm "100te Dateien" erzeugt, die das andere wieder einlesen muss.
:
Bearbeitet durch User
Kater schrieb: > Also, wenn man ein ISO-Image öffnet, legt Windows automatisch eine > virtuelle Partition an. Also existiert sowas doch in Windows. Man muß es > nur programmtechnisch ansprechen und verwalten können. Um ein ISO-Image als Filesystem lesend zu öffnen benötigt man ein lediglich einen Filesystemtreiber für ISO, der ein Diskfile als Storage-Device nutzen kann. Letzteres ist der einzige Unterschied zu ISO auf CD/DVD. Mit RAM hat das nichts zu tun.
Was Windows kann: Tempfiles so anlegen, dass Disk-Zugriffe nur dann involviert sind, landen, wenn es im RAM knapp wird. Aber da das von Bits im File-API gesteuert wird, müssen die Programme mitspielen. Hier also keine Option.
Kater schrieb: > Thomas_jhfd schrieb: > >> chade dass Windows von Haus aus keine Möglichkeit bietet. > > Also, wenn man ein ISO-Image öffnet, legt Windows automatisch eine > virtuelle Partition an. Also existiert sowas doch in Windows. Man muß es > nur programmtechnisch ansprechen und verwalten können. Was bringt ihm das in Windows fest eingebautes virtuelles Dateisystem für ISO Images bei seiner Anforderung? Eine Ramdisk implementiert die selbe API aber die bekommt er ohne Admin Rechte nicht geladen, was hier sein Problem ist Unter Windows gibt es keine eingebaute Ramdisk die per Default aktiv ist die er für so was nutzen könnte
Rolf M. schrieb: > und nirgends hat er behauptet, dass er diese zwei Programme selbst > geschrieben hätte. Wir befinden uns in: Forum: PC-Programmierung
Rolf M. schrieb: > Er hat also ein fertiges Programm, dem er per IPC sagen > kann, dass es eine Datei erstellen und auf der Platte speichern soll. nur das es keine Missverständnisse gibt "IPC" bedeutet hier nicht Industrie-PC sondern Interprozess-Kommunikation :)
MaWin schrieb: > Rolf M. schrieb: >> und nirgends hat er behauptet, dass er diese zwei Programme selbst >> geschrieben hätte. > > Wir befinden uns in: > Forum: PC-Programmierung Ich empfehle, mein Posting und das des TE nochmal durchzulesen und zu versuchen, es zu verstehen. Vor allem die Bedeutung dieses Satzes: Rolf M. schrieb: > "Das Programm" hat er doch gar nicht geschrieben, sondern nur dessen > Fernsteuerung. Kann es sein, dass du es darauf anlegst, die Frage falsch zu verstehen?
Rolf M. schrieb: > Kann es sein, dass du es darauf anlegst, die Frage falsch zu verstehen? Was soll der Blödsinn? Ich habe die Frage anscheinend falsch verstanden. Das haben wir ja jetzt geklärt. Die Ursachen dafür, dass jemand eine Frage falsch versteht, liegen in der Regel beim Fragesteller. Sie war offensichtlich nicht eindeutig gestellt.
Thomas_jhfd schrieb: > per COM (VBA oder .NET) automatisiere ich zwei Programme. > Aus dem einen Programm exportiere ich 100te Dateien, die in dem anderen > Programm wieder eingelesen werden. ER wollte nur den UMweg über die Festplatte sparen. Also wäre Ramdisk schon schön WENN der RAM reicht. Gleichzeitig sind aber alle Daten verloren wenn mal der Strom fehlt. Also doch copy irgendwas nach x:\irgendwo
Wir kennen jetzt keine Details zu deinem Code, aber vielleicht schlucken die über Com+ aufgerufenen Funktionen ja named pipes als file handle. Die wurden ursprünglich mal genau dazu erfunden. Stickworte "named pipe" und NPFS (named pipe file system) Musst du dich eventuell etwas einlesen. Oder jemand anders hier hat Erfahrung damit. https://versprite.com/blog/security-research/microsoft-windows-pipes-intro/ Grüße, M
oszi40 schrieb: > Gleichzeitig sind aber alle Daten > verloren wenn mal der Strom fehlt. Die Daten werden wohl von dem einen Programm exportiert und dann vom anderen importiert. Bei Stromausfall ist ein Datensatz korrupt - wäre er aber in jedem Fall.
Dirk B. schrieb: > Die Daten werden wohl von dem einen Programm exportiert und dann vom > anderen importiert. Bei Stromausfall ex-und importiert da nix mehr. Oliver
cppbert3 schrieb: > Hier checken es wieder einige nicht, oder? > Er hat eine Fremd Applikation die er über COM automatisieren kann, das > automatisierte Programm bietet nur diese Schnittstelle mit Dateiausgabe, > er kann daran nichts ändern, hat nichts mit seinem Code zu tun Genau so ist es. Zwei Programme, die ich nehmen muss wie sie sind. Dachte das wäre klar. Scheinbar nicht. Danke.
Deine eigentliche und unverständliche Einschränkung ist halt das hier: Thomas_jhfd schrieb: > Klar, eine Ramdisk wäre das Mittel der Wahl. > Geht aber anscheinend nur mit externen Tools. > Schade dass Windows von Haus aus keine Möglichkeit bietet. Wo ist das Problem? Oliver
Thomas_jhfd schrieb: > Zwei Programme, die ich nehmen muss wie sie sind. Ja dann ist doch alles klar. Nimm sie, wie sie sind, und gib dich geschlagen.
Da ist das Problem: Thomas_jhfd schrieb: > Da meine SW auf Fremdrechnern installiert wird sollte das möglichst mit > Bordmitteln gehen. Wenn ich das wie eine Library in meine Solution packen kann wäre das ok. Ich möchte aber nicht, dass der User weitere SW installieren und einrichten muss. Per Copy & Paste über die Zwischenablage ist noch naheliegend. Geht auch prinzipiell. Hat aber Nachteile wegen fehlender Einstellmöglichkeiten, die der Export als Datei bietet. Wenn es keine Möglichkeit gibt das innerhalb meiner Solution selbst umzusetzen bleibt es halt wie es ist. Der Poweruser hat ja immer noch die Möglichkeit seinen temporären Ordner selbst in eine Ramdisk zu legen.
Thomas_jhfd schrieb: schrieb: > Wenn ich das wie eine Library in meine Solution packen kann wäre das ok. Eigentlich gibt es da kein allzugroßes Problem. Für reine C&P-"Programmierer" wirds aber vermutlich schwierig. Oliver
Thomas_jhfd schrieb: schrieb: > Wenn ich das wie eine Library in meine Solution packen kann wäre das ok Du schreibst doch, dass du an der Software nicht das geringste ändern kannst - was soll da eine Library helfen? Die Funktionen muss man aus der Software heraus aufrufen. Georg
Der To bastelt eine "Solution", die die beiden unveränderlichen Programme fernsteuert. Ob es sich bei dem "Solution"-Basteln um Programmieren oder etwas anderes handelt, ist allerdings noch nicht ganz klar. Oliver
Oliver S. schrieb: > Eigentlich gibt es da kein allzugroßes Problem. Für reine > C&P-"Programmierer" wirds aber vermutlich schwierig. Dann lass mal hören.
Georg schrieb: > Thomas_jhfd schrieb: schrieb: >> Wenn ich das wie eine Library in meine Solution packen kann wäre das ok > > Du schreibst doch, dass du an der Software nicht das geringste ändern > kannst - was soll da eine Library helfen? Die Funktionen muss man aus > der Software heraus aufrufen. > > Georg Er hat 2 Applikationen die er beide per COM fernsteuert - die eine Importiert, die andere Exportiert - da ist noch sein dritte im Bunde ist das echt alles so schwer?
Oliver S. schrieb: > Thomas_jhfd schrieb: schrieb: >> Wenn ich das wie eine Library in meine Solution packen kann wäre das ok. > > Eigentlich gibt es da kein allzugroßes Problem. Für reine > C&P-"Programmierer" wirds aber vermutlich schwierig. > > Oliver Er schrieb doch das er die Software wenn möglich ohne zusätzlichen Aufwand auf Fremd-Rechnern installieren will - eine RAMDisk bedürfte mindestens Admin-Rechte - vielleicht bekommt er die einfach nicht
Wie soll denn das hier: Thomas_jhfd schrieb: > Ist es möglich die Dateien im RAM anstatt auf der Festplatte > zwischenzuspeichern? mit dem hier: Thomas_jhfd schrieb: > Genau so ist es. Zwei Programme, die ich nehmen muss wie sie sind. zusammenpassen? Wie soll man ein Programm, an dem man nichts verändern kann, dazu bringen auf eine RAM-Disk zu schreiben anstatt auf die Festplatte? Wie soll man ein Programm, an dem man nichts verändern kann, dazu bringen von einer RAM-Disk zu lesen anstatt von der Festplatte?
Mark B. schrieb: > Wie soll man ein Programm, an dem man nichts verändern kann, dazu > bringen auf eine RAM-Disk zu schreiben anstatt auf die Festplatte? Den Pfad, wohin exportiert wird, kann er vermutlich per COM Schnittstelle beeinflussen. Oder er erstellt einen Symlink zu einem Verzeichnis auf der RAM-Disk. Nur wie man automatisiert unter Windows eine RAM-Disk anlegt, dass weiß ich nicht. Bin kein Windows Spezialist.
Mark B. schrieb: > Wie soll man ein Programm, an dem man nichts verändern kann, dazu > bringen auf eine RAM-Disk zu schreiben anstatt auf die Festplatte? > > Wie soll man ein Programm, an dem man nichts verändern kann, dazu > bringen von einer RAM-Disk zu lesen anstatt von der Festplatte? Konfiguration. In einer Datei, Registry, oder als Parameter beim Aufruf, setzen, wo die Daten liegen. Und wenn das nicht möglich ist, gibt es noch Symlinks.
Mark B. schrieb: > Wie soll man ein Programm, an dem man nichts verändern kann, dazu > bringen auf eine RAM-Disk zu schreiben anstatt auf die Festplatte? Über COM ( https://de.wikipedia.org/wiki/Component_Object_Model )kann man z.B Excel und Word genauso fernsteuern wie über das eingebaute VBA. Du öffnest z.B eine Tabelle in Excel, exportierst bestimmte Daten in eine Datei (den Dateinamen kann man übergeben) und liest die mit einem anderen Programm wieder ein, das diese Datei dann im eigenen Format ablegt. Ein Ähnliches Vorgehen soll jetzt wohl mehrere Hundert mal erfolgen. COM unterstützen einige Programme.
🐧 DPA 🐧 schrieb: > Konfiguration. In einer Datei, Registry, oder als Parameter beim Aufruf, > setzen, wo die Daten liegen. Dann müsste eine solche Möglichkeit bereits in der Software vorgesehen sein. Wenn der Programmierer das nicht konfigurierbar gemacht hat, dürfte es schwierig werden es zu konfigurieren ;-) > Und wenn das nicht möglich ist, gibt es noch Symlinks. Um die zu nutzen, müsste man nach meinem Verständnis wiederum die bereits bestehenden Tools auch konfigurieren können. Nämlich so, dass sie für das Lesen/Speichern von Dateien eben einem Symlink folgen und nicht das Verzeichnis nutzen, welches fest einprogrammiert (?) ist.
Stefan ⛄ F. schrieb: > Nur wie man automatisiert unter Windows eine RAM-Disk anlegt, dass weiß > ich nicht. Bin kein Windows Spezialist. Man könnte eine Anleitung dazu schreiben, wie man das macht, und die dem Benutzer zum Befolgen geben. Entwickler schreiben immer gerne Dokumentation, und Benutzer lesen diese immer gerne. ;-)
Mark B. schrieb: > Um die zu nutzen, müsste man nach meinem Verständnis wiederum die > bereits bestehenden Tools auch konfigurieren können. Nämlich so, dass > sie für das Lesen/Speichern von Dateien eben einem Symlink folgen und > nicht das Verzeichnis nutzen, welches fest einprogrammiert (?) ist. Sofern das Programm nicht explizit angibt, dass das OS Symlinks nicht folgen soll, (z.B. unter Linux mit O_NOFOLLOW Option für open, Win hat da sicher etwas ähnliches), tut das OS das automatisch. Das ist ja genau der Sinn der Sache. Ein Symlink ist nicht das selbe wie diese .lnk Dateien, die vom Explorrer ausgewertet werden. Wobei, bei MS gibt es eigentlich keine echten Symlinks, sondern Reparse Points, und da gibt es viele verschiedene. Wie auch immer, man erstellt die Dinger unter Win mit mklink [1], du kannst ja selbst mal etwas damit rum spielen. Ich nutze die Dinger gerne, damit Programme nicht merken, dass die auf einen Netzwerkshare und gar nicht lokal schreiben (was wiederum geht, weil ein reparse point eben nicht das selbe wie ein symlink ist, und das dort irgendwie merkwürdig vom darunterliegenden Dateisystemtreiber mit beeinflusst wird...) PS: Was ist eigentlich der Unterschied zwischen "directory symbolic link" und "Directory Junction"? 1) https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink
Btw. Das konfigurieren des Programms ist nicht notwendig, weil man einfach (die im Programm fix angegebene) Zieldatei oder das Zielverzeichnis mit einem Symlink ersetzt.
Mark B. schrieb: > Um die zu nutzen, müsste man nach meinem Verständnis wiederum die > bereits bestehenden Tools auch konfigurieren können. Nämlich so, dass > sie für das Lesen/Speichern von Dateien eben einem Symlink folgen und > nicht das Verzeichnis nutzen, welches fest einprogrammiert (?) ist. Das ist nicht richtig. Ein Symlink ist keine *.lnk Datei wie sie der Dateimanager erstellt wenn man eine Verknüpfung auf eine Datei anlegt. Symlinks sehen für gewöhnliche Programme (die diese nicht speziell behandeln) wie ein Verzeichnis oder eine Datei aus, je nach dem, worauf der Symlink zeigt.
🐧 DPA 🐧 schrieb: > PS: Was ist eigentlich der Unterschied zwischen "directory symbolic > link" und "Directory Junction"? https://en.wikipedia.org/wiki/NTFS_reparse_point
Stefan ⛄ F. schrieb: > Das ist nicht richtig. Ein Symlink ist keine *.lnk Datei wie sie der > Dateimanager erstellt wenn man eine Verknüpfung auf eine Datei anlegt. > > Symlinks sehen für gewöhnliche Programme (die diese nicht speziell > behandeln) wie ein Verzeichnis oder eine Datei aus, je nach dem, worauf > der Symlink zeigt. Ah, jetzt, ja :-) Also quasi so: Vorher: Verzeichnis C:\hier\schreiben in Programm 1 Verzeichnis C:\hier\lesen in Programm 2 Beides richtige Verzeichnisse, keine Symlinks. Nachher: Symlink C:\hier\schreiben --> R:\in\wahrheit\aber\hier in Programm 1 Symlink C:\hier\lesen --> R:\in\wahrheit\aber\dort in Programm 2 Beides Symlinks, keine Verzeichnisse. Dann dürfen C:\hier\schreiben und C:\hier\lesen im Nachher-Fall nicht mehr als Verzeichnisse existieren, sondern nur noch als Links. An der Stelle war mein Denkfehler. Aua! ;-) Jetzt wäre noch die Frage, ob man irgendwie geschickt solche Symlinks automatisiert erzeugen kann, mit Hilfe eines Installers.
Danke für die konstruktiven Beiträge. Zum Verständnis, so in etwa sieht es bei mir aus:
1 | string svgFile Path.GetTempPath() + "item.svg"; |
2 | |
3 | foreach(var article in stock.articles) |
4 | {
|
5 | article.ExportAsImage(svgFile); |
6 | page.AddPicture(svgFile); |
7 | } |
Und wie kommst du nun auf den Trichter, dass die Platte das Bottleneck ist? Wenn die Dateien nicht gerade im Gigabytebereich liegen, dürfte die Geschwindigkeit der Platte kaum was ausmachen. Könnte man ja einfach mal testen ...
Keine Ahnung, wie Windows es handhabt, aber unter Linux werden kurzlebige Dateien in der Regel gar nicht auf die Festplatte geschrieben. Wenn man also eine Datei schreibt, liest und innerhalb weniger Sekunden wieder löscht, kommt es in der Regel zu gar keinem Disk-I/O. Kann Windows das auch?
MaWin schrieb: > Kann Windows das auch? Doch Doch!So war das mal angedacht. Deshalb ist RAMDISK ja unter WIndows auch totaler Quatsch. Erste Versuche 1992-94 unter MS-DOS Animationen zu erzeugen (Gab da so haufen "Multimedia CDs" mit dieversen Raytracing-Programmen undsowasalles). Da war so ne 4MByte-RAMDISK Goldwert. Hat man sich dann später auf seine 340MB-Platte kopiert, wenn man ferig war. Das ist doch aber alles "OPA erzählt vom Krieg" und längst obsolete, das wird doch alles zwischengespeichert, das landet wenn Zeit ist auf der Platte. Nun wissen wir natürlich auf der Anderen Seite nicht, welche programme hier involviert sind. kann schon sein, das Program "A" da n Flush(heisst das so?) erzwingt und die Datei erstmal aufs Laufwerk speichern will. Exakt dorthin, wo es angesagt wurde.
Thomas_jhfd schrieb: > Danke für die konstruktiven Beiträge. Wenn Windows da wirlich exzessiv die Platte verwendet, würde ich versuchen, ob sich das Verhalten ändert, wenn man die Datei gleich wieder löscht.
1 | string svgFile Path.GetTempPath() + "item.svg"; |
2 | |
3 | foreach(var article in stock.articles) |
4 | {
|
5 | article.ExportAsImage(svgFile); |
6 | page.AddPicture(svgFile); |
7 | unlink(svgFile); |
8 | } |
mmm schrieb: > Wenn Windows da wirlich exzessiv die Platte verwendet, würde ich > versuchen, ob sich das Verhalten ändert, wenn man die Datei gleich > wieder löscht. hört doch bitte mal auf - das ist doch alles nur noch Unfug was hier an den Post gehängt wird
Axel R. schrieb: > 1992-94 [..] Da war so ne 4MByte-RAMDISK Goldwert. Da musste man aber erst einmal 4 MB RAM frei haben, oder überhaupt 4 MB RAM haben :)
Wie ich oben geschrieben habe, versuch mal, ob deren API named pipes schlucken. Die sind die Windows Lösung für solche IPC Aufgaben. Das ist quasi eine virtuelle Datei, allerdings nicht einem eigenen Namensraum, nicht innerhalb der üblichen Laufwerksstruktur. Darf man Fragen welche zwei Programme du steuerst? Gibt's eventuell ne Doku zur COM Schnittstelle? Oder wenigstens die Deklaration der Funktionen ExportAsImage und AddPicture? Vielleicht schlucken die ja noch andere Typen als Argument Pfad, z. B. sowas wie ein streamIO Objekt oder Ähnliches.
Mark B. schrieb: > Jetzt wäre noch die Frage, ob man irgendwie geschickt solche Symlinks > automatisiert erzeugen kann, mit Hilfe eines Installers. Dazu gibt es den mklink Befehl und die Funktion CreateSymbolicLinkA() in der Windows API (winbase.h).
Stefan ⛄ F. schrieb: > Wenn du unter Linux Dateien speicherst und kurz danach wieder lädst, > werden sie automatisch im RAM gepuffert. Ist das bei Windows etwa > anders? Du hast recht, daran habe ich gar nicht gedacht. Eine Analyse mit einigen 1000 Dateien bestätigt deine Vermutung. Das Problem ist der SVG Export, der nur einen Kern nutzt. Andere Formate gehen schneller, haben aber andere Nachteile. Danke an alle!
Thomas_jhfd schrieb: > Du hast recht, daran habe ich gar nicht gedacht. > Eine Analyse mit einigen 1000 Dateien bestätigt deine Vermutung. > Das Problem ist der SVG Export, der nur einen Kern nutzt. Ich weiß ja nichts über die Inhalte Deiner SVGs, aber vielleicht wäre es auch möglich, die Rohdaten zu exportieren und die SVG-Wandlung mit etwas anderem zu machen? Gerade wenn die Daten auf so viele Dateien verteilt werden, schreit das ja geradezu nach einer Parallelisierung...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.