Hirdetés
- kraftxld: Diáklaptop - Dell Latitude 3140 - Királyunk ajándéka
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Magga: PLEX: multimédia az egész lakásban
- gban: Ingyen kellene, de tegnapra
- GoodSpeed: 3I/Atlas: Üstökös vagy idegen civilizáció űrhajója?
- sh4d0w: StarWars: Felismerés
- Gurulunk, WAZE?!
- Klaus Duran: Kerítésléc fail.
- Meggyi001: A kérdés...
- Luck Dragon: Asszociációs játék. :)
-
LOGOUT
Új hozzászólás Aktív témák
-
#8419
emvy
félisten
beleszólok
#8418
válasz
beleszólok
#8418
üzenetére
Teljesen overengineeringnek hangzik (foleg, hogy lathatoan azert _annyira_ nem vagy meg tapasztalt fejleszto), de ha ez kell, akkor par lehetoseg:
- http://zeromq.org/ --> ez nagyon gyors platform- es nyelvfuggetlen MQ implementacio
- a feldolgozo-resz siman egy webservice-en keresztul kommunikal -
#8417
emvy
félisten
beleszólok
#8416
válasz
beleszólok
#8416
üzenetére
Rosszul emlekszel az IPC-re.
Ha helyben akarod csinalni, akkor ne IPC-zz, marhasag. Csinalj egy library-t, ami feldolgoz, es csinalj egy UI-t, ami a libet hasznalja; tok feleslegesnek tunik ket processzbe rakni.
-
#8415
emvy
félisten
beleszólok
#8414
válasz
beleszólok
#8414
üzenetére
100 MB az nagyobb adatmennyiseg? WTF?
A logfaljos kerdesed tulsagosan altalanos. Csak helyben szeretned elvalasztani a feldolgozast a megjelenitestol? Vagy kulon gepen futna a parszer es az UI?
-
#8413
emvy
félisten
beleszólok
#8412
válasz
beleszólok
#8412
üzenetére
A posix mq az gepen beluli kommunikaciora valo. Kepzeld el ugy, mint egy named pipe egy csomo extra szolgaltatassal.
-
#8406
McSzaby
őstag
beleszólok
#8405
McSzaby
őstag
válasz
beleszólok
#8405
üzenetére
pffff... király vagy, ez így király lesz, nagyon szépen köszönöm!
-
#8404
McSzaby
őstag
beleszólok
#8403
McSzaby
őstag
válasz
beleszólok
#8403
üzenetére
Nagyon rendes vagy, köszönöm!
-
#8399
Jim-Y
veterán
beleszólok
#8398
Jim-Y
veterán
válasz
beleszólok
#8398
üzenetére
Szerintem ez nem gáz, ez csak simán így van: [link]
-
#8396
PumpkinSeed
addikt
beleszólok
#8392
PumpkinSeed
addikt
válasz
beleszólok
#8392
üzenetére
Akkor jó.
(#8393) martonx
A Tour of Go-val kezdtem nem tudom mi tudná jobban elmagyarázni a nyelv alapjait mint a nyelv saját oktató oldala.
"Egy adott nyelven megtanulni programozni" - mellette folyamatosan hallgatom az egyetemi anyagot.
(#8394) Jim-Y
Voltam pár helyi IT konferencián amire szabad bejárása volt bárkinek, voltak elődadások a modern webfejlesztési technikákról, és a jövő ilyesfajta technikáiról és mindenhol a Go-t taglalták mint a webfejlesztés új dimenzióját backend területen. Illetve egyik ismerősöm jelentkezett egy londoni céghez munkára webfejlesztőnek ahol közölték, hogy a jelenlegi PHP alatt futó rendszerüket Go alapokra akarják helyezni. -
#8374
Jester01
veterán
beleszólok
#8372
Jester01
veterán
válasz
beleszólok
#8372
üzenetére
A for ciklusos változat nálam gyorsabb mint a python.
-
#8369
amargo
addikt
beleszólok
#8368
amargo
addikt
válasz
beleszólok
#8368
üzenetére
ez elkerülte a figyelmem, hogy linux alatt akarod használni, felejtsd el. Miért nem jó a python-os megoldás?
-
#8367
amargo
addikt
beleszólok
#8366
amargo
addikt
válasz
beleszólok
#8366
üzenetére
Amit Te szeretnél a .net nél úgy hívják, hogy powershell érdemes lenne átírnod rá. A hiányolt funkcióból is egyből feltűnt, hogy nem egy monolitikus eszközre van szükséged.
-
#8365
Jester01
veterán
beleszólok
#8364
Jester01
veterán
válasz
beleszólok
#8364
üzenetére
Igen, a hibát akkor kapod ha nem választod ki a project options->general->c#->main class segítségével, hogy melyiket is akarod használni. Ez egyébként visual studioban is így van: To resolve this error, you can either delete all Main methods in your code, except one, or you can use the /main compiler option to specify which Main method you want to use.
Mondjuk továbbra sem látom ennek mi értelme van. Ha különböző programokat akarsz csinálni akkor tedd őket külön projektbe.
-
#8361
Alexios
veterán
beleszólok
#8360
Alexios
veterán
válasz
beleszólok
#8360
üzenetére
solution-ben végtelen projekted lehet, és projektenként lehet main metódusod.
-
#8359
Jester01
veterán
beleszólok
#8355
Jester01
veterán
válasz
beleszólok
#8355
üzenetére
Az IndexOf vagy a for ciklus? Mert az előbbi nekem is lassabb mint a python.
Monodeveloppal mi bajod? -
#8358
sztanozs
veterán
beleszólok
#8357
válasz
beleszólok
#8357
üzenetére
A core runtime nem tűnik szerver-oldal only-nak, de majd utánanézek...
-
#8356
sztanozs
veterán
beleszólok
#8355
válasz
beleszólok
#8355
üzenetére
-
#8352
Jester01
veterán
beleszólok
#8351
Jester01
veterán
válasz
beleszólok
#8351
üzenetére
linux+mono persze (a pingvinből azért lehetett sejteni
)
Egy szálon a mono így "csak" kétszer lassabb, többszálúsítva utoléri.Hehe, az IndexOf-nál sokkal gyorsabb ha simán ciklusban végignézzük:
for(int pos = 0; pos < got; pos += 1)
{
if (buf[pos] == 10) n += 1;
}Ez már egy szálon is ráver a pythonra így.
-
#8350
Jester01
veterán
beleszólok
#8349
Jester01
veterán
válasz
beleszólok
#8349
üzenetére
A háttérben zajló karakterkészlet konverzió és memóriaműveletek lassítják a dolgot, ezek elkerülhetők némi kézi mókolással:
public static void Main(string[] argv)
{
int n = 0;
byte[] buf = new byte[4096];
using (Stream s = File.OpenRead("kern.log"))
{
int got;
while ((got = s.Read(buf, 0, buf.Length)) > 0)
{
int pos = 0;
while (pos < got && (pos = Array.IndexOf(buf, (byte)10, pos)) >= 0)
{
n += 1;
pos += 1;
}
}
}
Console.WriteLine (n);
}Ez nálam nagyjából fele olyan gyors mint a python változat.
Többszálúsítva sikerül beérni sebességben. -
#8349
beleszólok
senior tag
beleszólok
#8348
beleszólok
senior tag
válasz
beleszólok
#8348
üzenetére
Közben kipróbáltam, hogy a linuxon fordított .exe-t átvittem windows-ra a loggal együtt. Ott már csak 8mp.
-
#8347
Peter Kiss
őstag
beleszólok
#8346
Peter Kiss
őstag
válasz
beleszólok
#8346
üzenetére
Hasonló fájllal 6-7 másodpercet tudok kihozni belőle, ami figyelembe véve a magasabb absztrakciót egyáltalán nem rossz.
-
#8345
Peter Kiss
őstag
beleszólok
#8312
Peter Kiss
őstag
válasz
beleszólok
#8312
üzenetére
Python unicode-ot olvas alapból?
A .NET verziót hányszor futtattad? (Első alkalommal még fordul a kód [üres fájlt be kell küldeni először].)
Mivel mérted az időket? -
#8344
sztanozs
veterán
beleszólok
#8342
válasz
beleszólok
#8342
üzenetére
Írhatsz esetleg a pull request-be is egy hosszú kommentet is - ha azt nem olvassa el, akkor hiába is akarod keresni
-
#8341
Sk8erPeter
nagyúr
beleszólok
#8339
Sk8erPeter
nagyúr
válasz
beleszólok
#8339
üzenetére
Egy - nem túl atombiztos - lehetőség van, mégpedig az, hogy checkoutolod a repository-ját, és a commit logokban a szerzőnél/commitolónál megnézed az e-mail-címét a felhasználóneve mellett.
Ez persze simán lehet nemlétező is (ha ilyet adott meg), vagy olyan, amit ritkán vagy szinte egyáltalán nem használ, de esélyes az is, hogy pont az az e-mail-cím lesz itt megtalálható, amire neked szükséged van. Egy próbát mindenképpen megér.(#8340) Jim-Y:
"Ha rámész a user nevére/profiljára, ott megtalálod az email címét"
Ez csak akkor igaz, ha a felhasználó a https://github.com/settings/profile oldalon kitöltötte az "Email (will be public)" mezőt. Egyébként nem látszik az e-mail-cím, és ez a gyakoribb, hogy ezt a mezőt nem töltik ki. -
#8340
Jim-Y
veterán
beleszólok
#8339
Jim-Y
veterán
válasz
beleszólok
#8339
üzenetére
Ha rámész a user nevére/profiljára, ott megtalálod az email címét. Vagy még sokszor van ilyen, hogy CONTRIBUTING.md, ott is találhatsz még contactot, esetleg ha van WIKI page-e a reponak ott is érdemes szétnézni.
A PR (pull request) azt jelenti, hogy ha átírsz valamit a forrásban, akkor egy PR készül, amit az eredeti gazda elfogadhat, mergelhet a kódba, így a változtatásod élesben is elérhető lesz mindenki számára, ha elfogadják.
Ez utóbbit jobban is le lehet írni, többféle képp is csinálhatod, amire most nem térek ki, a lényege úgyis mindnek ez.
-
#8339
beleszólok
senior tag
beleszólok
#8338
beleszólok
senior tag
válasz
beleszólok
#8338
üzenetére
Nincs.
Nem én vagyok az oka, hogy nem találtam: volt lehetőség privát üzeneteket küldeni, de megszüntették.
E-mail meg csak az látszik, amit a user külön megad, amivel regisztrált, az nem jelenik meg sehol. -
#8329
sztanozs
veterán
beleszólok
#8320
válasz
beleszólok
#8320
üzenetére
Debug üzemmódban teszteled a c#-ot sebességre, vagy Release-ben?
-
#8324
martonx
veterán
beleszólok
#8323
martonx
veterán
válasz
beleszólok
#8323
üzenetére
Hát, ez esetben nagyon gáz a C# 22mp-es olvasás ideje.
-
#8321
martonx
veterán
beleszólok
#8320
martonx
veterán
válasz
beleszólok
#8320
üzenetére
Egyébként nekem gyanús, hogy vagy a Python csal (mondjuk a fordító figyeli, hogy csinálsz-e bármit a beolvasott adattal, és ha nem akkor valahogy eleve csak végigpörgeti a file-t, érdemi beolvasás helyett), vagy a C# mono-val nagyon nincs optimalizálva. Vagy mindkettő. Elvileg közel nulla különbségnek kellene lennie pusztán a file megnyitásakor, végigpörgetésekor a két nyelv között.
Nekem egyébként kicsit gyanús, hogy a Python az 1.6Gb-os file-t 3.6 másodperc alatt nyálazza végig, ez kicsit mintha túl kevés lenne.
-
#8319
martonx
veterán
beleszólok
#8316
martonx
veterán
válasz
beleszólok
#8316
üzenetére
ha már próblgatunk, akkor ezt próbáld még ki C#-al, a komplett using-os rész helyett:
foreach (var line in File.ReadLines("kern.log"))
{
n++;
}Így legalább már pont olyan szép, mint python-nal
És amikor ezzel megvagy, akkor javaslom még a foreach helyett a parallel.foreach-et kipróbálni. Erre gondoltam eredetileg, amikor mondtam, hogy C#-al nagyon egyszerű több processzor magot kihasználni.
Én anno C#-al (mondjuk nem mono-val, hanem rendes C#-al windows-on) 40Gb-os XML-eket parsoltam, és dolgoztam fel, töltöttem db-be pár órás futásidővel (igaziból a db-be töltés volt a szűk keresztmetszet, pontosabban a db mögötti storage, mivel a DB szerver 96 magos, alig terhelt gép volt).
-
#8317
#39560925
törölt tag
beleszólok
#8316
#39560925
törölt tag
válasz
beleszólok
#8316
üzenetére
és ha a while ciklusban nem adnál értéket egy stringnek?
-
#8315
Sk8erPeter
nagyúr
beleszólok
#8314
Sk8erPeter
nagyúr
válasz
beleszólok
#8314
üzenetére
Mondjuk ha a "blog-jellegű panasz" valamilyen kódot is tartalmazna, hogy miként is működtél, akkor lehet, hogy lehetne rá érdemben is reagálni, és esetleg jobb módszert mutatni.
Amivel a panasz esetleg enyhíthető.
Vagy nem, de ez eddig még nem derült ki. -
#8313
Karma
félisten
beleszólok
#8312
Karma
félisten
válasz
beleszólok
#8312
üzenetére
Ennyi információval nem sokat lehet mondani rá
Az ördög valószínűleg a részletekben van, és ki lehetne mérni, mégis hol veszik el ennyi idő. -
#8306
martonx
veterán
beleszólok
#8304
martonx
veterán
válasz
beleszólok
#8304
üzenetére
Szerintem kevered a namespace-t és a workspace-t.
-
#8302
martonx
veterán
beleszólok
#8299
martonx
veterán
válasz
beleszólok
#8299
üzenetére
Én Visual Studio-t használok, ott nem tapasztaltam ilyen problémát. Ebben nem tudok tanácsot adni.
-
#8301
Karma
félisten
beleszólok
#8299
Karma
félisten
válasz
beleszólok
#8299
üzenetére
Az lehet a kiváltó ok, hogy tévesen vontál le egy következtetést pár hozzászólással ezelőtt: a solution nem a projekt megfelelője más környezetekből.
Visual Studioban (és itt is) a projekt a legkisebb fordítható egység, aminek a kimenete projekttípustól függően egy DLL, futtatható fájl, csomag, stb. Vagy más szóval egy modul, Pythonban meg kb. a package felel meg ennek, csak komplexebb.
A solution ilyen projekteket fog össze, és lehetővé teszi a kereszthivatkozásokat közöttük. Ezt meg máshol workspace-nek szokták hívni.
A regexes példádnál nem a solution, hanem a C# projekt hiányzott - enélkül nem tudja az IDE, melyek framework verziót húzza be és mi a kimenet, inkább nem is csinált semmit.
Azt viszont nem tudom, miért nincsenek nevek a tabokon. Xamarin Studio alatt még nem volt ilyen bugom.
-
#8300
j0k3r!
őstag
beleszólok
#8299
j0k3r!
őstag
válasz
beleszólok
#8299
üzenetére
Nem ismerem MonoDevelop-ot, de Visual Studio is ugyanezt csinálja a File -> New Project-nél. A felső mappa a Solution-nek, az alatta levő pedig a Project-nek van létrehozva. (habár Visual Studio-ban van egy checkbox erre, hogy "Create directory for solution")
-
#8297
martonx
veterán
beleszólok
#8296
martonx
veterán
válasz
beleszólok
#8296
üzenetére
Tök jó, örülök! Jelzem a mono-ban egyre jobban bízhatsz, mivel a jövő év elején megjelenő C# 6-tal a Microsoft a mono-t is beemeli a hivatalosan támogatott futtató környezetek közé.
-
#8296
beleszólok
senior tag
beleszólok
#8295
beleszólok
senior tag
válasz
beleszólok
#8295
üzenetére
Na, egy hiba kilőve: ha létrehozok neki "project"-et (a fene gondolta, hogy a "solution" jelenti azt, amit máshol a project), akkor már megtalálja a monodevelop is a regexp könyvtárat.
És így megvan az a References is, amit korábban nem találtam, mivel nem hoztam létre ezt a solution-nek nevezett dolgot. -
#8293
martonx
veterán
beleszólok
#8292
martonx
veterán
válasz
beleszólok
#8292
üzenetére
Ha nem ragaszkodsz a pythonhoz, mondjuk C#-ál bagatell egyszerű több szálú feldolgozót írnod. Akár Pythonból is meg tudod hívni szimpla konzol alkalmazásként.
-
#8291
sztanozs
veterán
beleszólok
#8290
válasz
beleszólok
#8290
üzenetére
ha a sorok feldolgozása nem egy nagyságrenddel nagyobb feladat, mint a beolvasás, úgy szerintem nem érdemes külön szálban foglalkozni vele...
-
#8284
beleszólok
senior tag
beleszólok
#8283
beleszólok
senior tag
válasz
beleszólok
#8283
üzenetére
Nem kéne ennyire keverni a nyelveket...
while($infile)-t írtam while(<$infile>) helyett...
-
#8281
#39560925
törölt tag
beleszólok
#8280
#39560925
törölt tag
válasz
beleszólok
#8280
üzenetére
)
Az ördög valószínűleg a részletekben van, és ki lehetne mérni, mégis hol veszik el ennyi idő.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- GYÖNYÖRŰ iPhone 13 Pro 256GB Sierra Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3359
- Bomba ár! Dell Latitude E7440 - i5-4GEN I 8GB I 256SSD I 14" FHD I HDMI I Cam I W10 I Gari!
- HIBÁTLAN iPhone 15 Pro Max 256GB Black -1 ÉV GARANCIA - Kártyafüggetlen, MS3495, 100% Akkumulátor
- Samsung Galaxy A23 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
- HIBÁTLAN iPhone 13 128GB Starlight -1 ÉV GARANCIA - Kártyafüggetlen, MS3917, 100% Akkumulátor
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopműhely Bt.
Város: Budapest