myCSharp.de - DIE C# und .NET Community
Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 
 | Suche | FAQ

» Hauptmenü
myCSharp.de
» Startseite
» Forum
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Suche
» Regeln
» Wie poste ich richtig?
» Forum-FAQ

Mitglieder
» Liste / Suche
» Wer ist wo online?

Ressourcen
» openbook: Visual C#
» openbook: OO
» Microsoft Docs

Team
» Kontakt
» Übersicht
» Wir über uns

» myCSharp.de Diskussionsforum
Du befindest Dich hier: Community-Index » Diskussionsforum » Entwicklung » Rund um die Programmierung » Macht Datenkompression immer Sinn?
Letzter Beitrag | Erster ungelesener Beitrag Druckvorschau | Thema zu Favoriten hinzufügen

Antwort erstellen
Zum Ende der Seite springen  

Macht Datenkompression immer Sinn?

 
Autor
Beitrag « Vorheriges Thema | Nächstes Thema »
Solix0x Solix0x ist männlich
myCSharp.de-Mitglied

Dabei seit: 01.02.2018
Beiträge: 6


Solix0x ist offline

Macht Datenkompression immer Sinn?

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hallo, die Frage steht ganz unten, aber ich erkläre erstmal meinen Gedankengang.

Nehmen wir mal folgendes Beispiel:

Man sehe sich eine Anwendung an, die Nachrichten/Daten verschickt (sowas wie WhatsApp, ein Online-Spiel, was auch immer). Und nehmen wir mal eine Beispielnachricht mit "Hallo Welt". In der Uni habe ich gelernt, dass man das ganze in Nullen und Einsen kodieren kann und Redundanz entfernen kann, sodass die Anzahl der zu verschickenden Bytes kleiner wird, aber nicht der Informationsgehalt. Letztendlich habe ich eine Folge von sagen wir "1110011". Diese 8 Bits kann man jetzt wiederum als Zahl auffassen, in dem Fall ist es die Zahl 115 und 115 als Hexadezimalzahl ist 73.

Und allgemein würde ich nun sagen, dass je höher die Basis des Zahlensystems ist, desto weniger Ziffern braucht man, um die Zahl darzustellen. Sieht man ja auch, mit der Basis 2 sind es 8 Ziffern, bei 10 dann 3, und bei 16 2. Jetzt könnte ich ein Zahlensystem konstruieren, dass wie das Hexadezimalsystem auch Buchstaben als Ziffern verwendet.

Und wenn ich dann einen längeren Text als "Hallo Welt", sagen wir einen Text mit 200 Zeichen verschicken will, dann kann ich mein Verfahren wie oben beschrieben anwenden und könnte dann sowas wie "jfI0" rausbekommen mit einem Zahlensystem mit einer sehr hohen Basis und dann verschicke ich nur diese 4 Zeichen.

Beim Empfänger kommt das relativ schnell an, man vergleiche 4 zu 200 Zeichen. Jedoch muss der Empfänger das dann so dekodieren, dass er an die ursprüngliche Information kommt.


Also könnte man Datenmengen über das Internet stark reduzieren, aber wenn man mal schaut, dann brauchen die meisten Spiele doch eine Gigabyte um heruntergeladen zu werden. Hat meine Idee irgendeinen Haken, ist es so nicht umsetztbar oder was auch immer? Ich denke, dass nicht nur ich jemals diese Idee gehabt hat.

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Solix0x am 10.07.2019 22:34.

10.07.2019 22:13 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
T-Virus T-Virus ist männlich
myCSharp.de-Mitglied

Dabei seit: 17.04.2008
Beiträge: 1.336
Entwicklungsumgebung: Visual Studio, Codeblocks, Edi
Herkunft: Nordhausen, Nörten-Hardenberg


T-Virus ist offline Füge T-Virus Deiner Kontaktliste hinzu

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Dein Ansatz hat mehr mit Datenkompression als Vershlüsselung zu tun.
Kodierung/Dekodierung passt nach deiner Beschreibung auch nur oberflächlich.
Besser wäre eben Kompression und Dekompression.

Dafür gibt es schon viele Varianten wie z.B. Zip oder xz, die auch abhängig von ihrem Einstellungen/Umsetzungen, auch unterschiedlich gut sind.

Hier muss man meistens zwischen CPU Last, Speicherverbrauch und Kompressionsrate unterscheiden.
Will man hohe Kompression erreichen, bedeutet dies hohe CPU Last und Speicherverbrauch.
Will man wenig CPU Last und Speicherverbrauch, dann muss man bei der Kompressionsrate Abstriche machen.

Datenkompression spielt bei einigen Spieleplatformen auch heute eine Rolle und ist auch entsprechend implementiert.
Hier werden die Daten sowohl Komprimiert als auch verschlüsselt übertragen und beim Empfänger entpackt sowie Entschlüsselt.

Nachtrag:
Spieledateien sind bereits stark komprimiert, weshalb dort kaum noch Datenmengen gespart werden können.
Würde man sämtliche Dateien eines aktuellen AAA-Titels unkomprimiert ausliefern, würde dies locker 1-2 größere Festplatten im TB Bereich füllen.
Hier sind vorallem Multimedia Dateien wie Musik/Sounds, 3D-Modelle und Texturen bereits durch ihre eigenen Formate vorkomprimiert.
Trotzdem müssen immer noch einige Gigabyte an Daten geladen werden.
Und dies eben obwohl diese schon stark komprimiert sind.
Du kannst dir mal anschauen was z.B. eine DVD oder Bluray Disc unkomprimiert an Daten fressen würde.
Da merkt man schon, dass heutige Verfahren schon unglaublich effizient aber auch sehr Hardware hungrig sind.

Du bist auch nicht der erste, der sich darüber gedanken macht.
Einige Protokolle zur Datenübertragung, sowohl im LAN als auch über das Internet, bieten eben über angebundene Kompressions Libs entsprechende build-in Kompression an.
Z.b. kann ich mit rsync Daten auch komprimiert über das Netz schieben und laden.
Nur hängt die Effizienz eben davon ab ob die Daten noch in der Rohform vorliegen oder durch ihr Format selbst schon komprimiert sind.

Eine 1GB Textdatei lässt sich locker auf 500MB oder weniger komprimieren.
Eine 1GB Zip Datei aber nur auf einige MB weniger, je nach Kompressionsverfahren, was angewendet wird.

T-Virus

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von T-Virus am 10.07.2019 22:41.

10.07.2019 22:28 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Solix0x Solix0x ist männlich
myCSharp.de-Mitglied

Dabei seit: 01.02.2018
Beiträge: 6

Themenstarter Thema begonnen von Solix0x

Solix0x ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Ah danke, ich habe erstmal den Titel vom Thema geändert :) Und sowas scheint dann doch nicht unüblich zu sein
10.07.2019 22:36 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
T-Virus T-Virus ist männlich
myCSharp.de-Mitglied

Dabei seit: 17.04.2008
Beiträge: 1.336
Entwicklungsumgebung: Visual Studio, Codeblocks, Edi
Herkunft: Nordhausen, Nörten-Hardenberg


T-Virus ist offline Füge T-Virus Deiner Kontaktliste hinzu

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

@Solix0x
Bitte lies auch meinen Nachtrag im Kommentar oben.
Unüblich wäre noch eine Untertreibung.
Kompression bei der Datenübertragung ist bei vielen Protokoll und Dateien möglich, aber eben nicht bei allen.
Es hängt eben auch von den Daten ab, ob man noch was komprimieren kann oder nicht.

Hier kannst du dich gerne weiter einlesen.
 Wiki: Datenkompression

T-Virus
10.07.2019 22:43 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 13.087
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat von T-Virus:
Eine 1GB Textdatei lässt sich locker auf 500MB oder weniger komprimieren.
Eine 1GB Zip Datei aber nur auf einige MB weniger, je nach Kompressionsverfahren, was angewendet wird.

Das hinkt an der Stelle; a) weil ZIP bereits prinzipiell eine Kompression darstellt / darstellen kann und b) eine Kompression verschiedene Stufen hat.
Man kann zB ZIP Dateien ohne Kompression erstellen (Container only).

Zitat von Solix0x:
Man sehe sich eine Anwendung an, die Nachrichten/Daten verschickt (sowas wie WhatsApp, ein Online-Spiel, was auch immer).

Datenkompression ist immer CPU-lastig, weshalb man sich überlegen muss, ob Kompression sinn macht.
Gerade bei Apps vermeidet man deswegen Kompression, denn die Mehrlast kostet Akku und bekommt dann vom Betriebssystem ein schlechtes Ranking, weshalb die Leute dann Apps runter schmeissen.

Kompression baut man sehr selten direkt in Anwendungen ein; sondern sind eher Teil der Infrastruktur.
Kompression macht die Sache der Kommunikation auch nicht zwangsläufig schneller.
10.07.2019 22:57 Beiträge des Benutzers | zu Buddylist hinzufügen
chilic
myCSharp.de-Poweruser/ Experte

Dabei seit: 12.02.2010
Beiträge: 2.012


chilic ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Ich möchte auf diese Aussage eingehen, denn ich habe das Gefühl die ist das Verständnisproblem in diesem Beitrag.

Zitat:
Und wenn ich dann einen längeren Text als "Hallo Welt", sagen wir einen Text mit 200 Zeichen verschicken will, dann kann ich mein Verfahren wie oben beschrieben anwenden und könnte dann sowas wie "jfI0" rausbekommen mit einem Zahlensystem mit einer sehr hohen Basis und dann verschicke ich nur diese 4 Zeichen.

Sagen wir du hast eine 4 stellige Zahl im Hexsystem und betrachtest die jetzt als 2 Bytes im "Byte System".
In deiner Aussage verwendest du den Begriff "Zeichen" verschieden. In meinem Beispiel wäre das einmal "4 Zeichen Hex" und "2 Zeichen als Byte". Du siehst hier den Vorteil dass du aus vier Zeichen zwei machen kannst. Es handelt sich aber nicht um den selben Zeichenvorrat!
Du musst nämlich auch berücksichtigen dass ein Byte doppelt so breit ist wie eine Hexziffer.
Es gibt 16 Hexziffern, aber 256 Byteziffern. 4 Hexziffern brauchen 4 x 4 Bit, die 2 Bytes brauchen 2 x 8 Bit. Also nichts gespart.
Die Sichtweise mit dem höheren Zahlensystem ist also rein gedanklich. Du hast 16 Bits und betrachtest die einmal als vier Hexziffern und das andere mal als zwei Bytes. Aber es bleiben trotzdem 16 Bit.

In deinem Beispiel schreibst du umgerechnet, du stellst einen Text mit 50 Zeichen durch ein einziges Zeichen dar. Auch hier ist Zeichen nicht gleich Zeichen.
Sagen der Text besteht aus 50 Bytes, also jede Stelle im Text kann 256 Möglichkeiten annehmen. Das ist der Zeichenvorrat "Typ A".
50 solche Bytes hintereinander ergeben 256^50 Möglichkeiten für den Text. (Zur Vorstellung, das ist eine Zahl mit 121 Stellen)
Dein Zeichenvorrat "Typ B", bei dem du für den Text nur ein einziges Zeichen brauchst, müsste also 256^50 verschiedene "Typ B Ziffern" enthalten.
Das heißt du hast dann gedanklich zwar nur eine einzige "Typ B Ziffer", aber um diese eine Ziffer eindeutig darzustellen wäre sie in Bits betrachtet wiederum so breit dass du den selben Platz brauchst.

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von chilic am 11.07.2019 06:13.

11.07.2019 06:11 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
pinki
myCSharp.de-Mitglied

avatar-4072.jpg


Dabei seit: 24.08.2008
Beiträge: 666
Herkunft: OWL


pinki ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

 Diese Folge des RFC-Podcasts erklärt Deflate ganz gut.
Daran kann man bei einem Verfahren also schon mal gucken, wie das dort gemacht wird.
11.07.2019 11:29 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Baumstruktur | Brettstruktur       | Top 
myCSharp.de | Forum Der Startbeitrag ist älter als 3 Monate.
Der letzte Beitrag ist älter als 3 Monate.
Antwort erstellen


© Copyright 2003-2019 myCSharp.de-Team | Impressum | Datenschutz | Alle Rechte vorbehalten. | Dieses Portal verwendet zum korrekten Betrieb Cookies. 23.10.2019 23:06