Hirdetés
- Bemutatkozott a Poco F2 Pro (már megint)
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Most a három Galaxy S25 képernyő bukott le
- Samsung Galaxy S23 Ultra - non plus ultra
- Samsung Galaxy S21 FE 5G - utóirat
- Garmin Fenix 8 AMOLED - a csúcshódítás költséges
- Poco F6 5G - Turbó Rudi
- LG G4 - nehéz rajta fogást találni
- iPhone topik
- Apple iPhone 15 - a bevált módszer
Új hozzászólás Aktív témák
-
joysefke
veterán
Saját szórakozásra implementálok egy Seam Carving algoritmust. Az algoritmus meg körülötte egy WPF ablak már kész van, prototípus szinten szépen működik (egyelőre full fapad, de müxik).
Én is tegnap jöttem rá -világított rá valaki redditen-, hogy a Color az sokat foglal, mindjárt meg is nézem mennyit. Eddig szembe sem jutott, hogy a Color az nem 4 byte (8+8+8+8 = A+R+G+B).
A szükségesnél magasabb memóriafoglalás egyelőre nem zavar, egy 13mpx-es kép esetén az applikáció teljes memóriafogyasztás "csak" 500-550mb. A sebesség viszont sokkal gázabb. Parallel.For(), taskok és nem managelt mem hozzáférés segítségével már volt némi gyorsulás
Na mind majd visszajövök
Athlon64:
A kép kirajzolása másodlagos, kétszer kell kirajzolni: miután betöltötte a képet, illetve miután lefutott az algoritmus a módosított képet.Ha lesz időm töltök fel konkrét kódrészleteket, hogy lássuk mit lehetne hatékonyabbá tenni. Lenne mit
[ Szerkesztve ]
-
#7902
joysefke
veterán
Peter Kiss
#7900
joysefke
veterán
válasz
Peter Kiss
#7900
üzenetére
Ha az nem is jó neked, akkor pl. én nem használnék Color-t, mert az kicsit túl nagy, helyette egy int is megteszi vagy egy kisebb saját típus.
Te jó ég, most megnéztem
Console.WriteLine(Marshal.SizeOf(new Color ())); -----> Ez 24-et ír ki a konzolra
Jól értelmezem, Color objektumonként 24 Byte + a tömb overheadje a memóriafoglalás???
Ez 13Mpx-nél (az egy átlagos kép) 13*24*E6 = 312MB+overhead...
Én meg annyira meg voltam győződve róla, hogy ez a Color objektum csak az RGBA értékeket tárolja 4byte-ban, és az a sok property amin keresztül ezt-azt le lehet kérdezni az is csak az RGBA értékeket kérdezgeti le/állítja be...
[ Szerkesztve ]
-
válasz
joysefke
#7902
üzenetére
private readonly string name;
// will contain standard 32bit sRGB (ARGB)
//
private readonly long value;
// ignored, unless "state" says it is valid
//
private readonly short knownColor;
// implementation specific information
//
private readonly short state;while (!sleep) sheep++;
-
Keem1
addikt
Srácok, mit rontok el?
KódA
Dictionary<string, List<string>> travel_data = new Dictionary<string, List<string>>();id-ját (string) ki tudom íratni, de aList<string>elemeit már nem.Egyébként létezik olyan univerzális dump, ami a paraméter változó, objektum, stb. adatait strukturáltan kiírja, mint pl. php-ban a
print_r()? Ilyen esetben nagy segítség lenne, hogy ténylegesen mi van az adott változóban.Ez a kimenet (az adat résznél (belső foreach) üres sorok):
Nyomjunk egy billentyűt a kezdéshez!
Beolvasandó fájl: TOROKORSZAG39.xml
=== Kész! 00:00:01.11 ===
YS4257=====
TMLMB4259=====
ADWP4282=====
SLR4284=====
TBRH4293=====
[ Szerkesztve ]
-
Froclee
őstag
Gondolom az xmlReader.Value nem az, ami neked kell. Nincs ilyen object dumper, breakpoint-ot szoktunk használni.
A kód is sántít itt-ott, az xml-ből 1-2 értéket be tudsz ide másolni? (ha érzékeny adat írd át a tartalmát) Hátha tudunk jobb parser írására sarkallni.
[ Szerkesztve ]
-
Keem1
addikt
válasz
Froclee
#7906
üzenetére
Valóban érzékeny adat, így csináltam egy lecsupaszított verziót
Az alapötlet onnan származik, hogy az eddigi DOM parsert akarom átírni, mivel adott esetben több száz, vagy akár GB-on felüli XML is létezik, így a ram telítődés (és a swappolás) hátrányai rögtön jelentkeznek. Ez az előbb 26 másodperc alatt szaladt végig egy kicsit több, mint 1 GB-os példányon, csak épp működésre bírni nem tudom.Köszönöm a segítséged!
Basszus!
Szerintem rájöttem a hibára!
travel_data[id].Add(xmlReader.Value);
HELYETT:travel_data[id].Add((XNode.ReadFrom(xmlReader) as XElement).Value);Lassan kiderül, hogy én bizony csak egy kontár vagyok...
[ Szerkesztve ]
-
Keem1
addikt
-
Goose-T
veterán
Miért nem deszerializálod streamből parseolás helyett? Ezerszer egyszerűbb és gyorsabb lenne, ráadásul memórialimit sem lenne. Csinálsz egy osztályt, feldekorálod XML attribútumokkal, oszt jóvan. Kiindulópontnak ez jó lehet.
Rockbandám: https://fb.me/scharlotterhodes *** Gitárelektronikai műhelyem: https://www.fb.me/goosetgitar
-
Goose-T
veterán
-
-
Sziasztok! ASP MVC alkalmazásomban van egy custom
IFilterProviderimplementációm. Szeretnék actor-ban végigmenni az összes alkalmazásban fellelhetőAction-on, hogy ki tudjam gyűjteni aHTTPPOSTattribútummal rendelkezőket.Nyilván az
IFIlterProvideráltal biztosítottGetFilters(ControllerContext controller, ActionDescriptor action)függvényen keresztül megy a dolog egyszerűen, de én az előtt szeretném ezt tudni, mielőtt ez a fv. meghívásra kerül.[ Szerkesztve ]
-
j0k3r!
senior tag
Ez kicsit zavaros, inkább azt írd le, hogy mit szeretnél csinálni
Lehet global ActionFilter-t írni, ami hamarabb fut le, mint az Action-ökön levő filterek, bár nem vagyok benne biztos, hogy neked ez kell. Illetve milyen verziójú ASP.NET MVC-t használsz?
mod: [link]
[ Szerkesztve ]
some men just wanna watch the world burn...
-
j0k3r!
senior tag
Szóval téged nem az érdekel, ha egy HttpPost-os action meghívódik, hanem az hogy kód szinten hány metódus van felannotálva (szép szó) a HttpPost attribútummal? Ez esetben én reflection-t használnék az Application_Start-ban. Kezdve a web alkalmazásod(assembly) összes osztályával, ami a System.Web.Mvc.Controller-ből származik, majd ezek publikus nem statikus metódusain ilyesmit nézni.
mod: ha nagyon elakadsz vele, akkor délután megírom ezt a pár sort
[ Szerkesztve ]
some men just wanna watch the world burn...
-
"Szóval téged nem az érdekel, ha egy HttpPost-os action meghívódik, hanem az hogy kód szinten hány metódus van felannotálva (szép szó) a HttpPost attribútummal?"
Pontosan
Az Application_Start-ot nem akarom teleszemetelni, viszont van benne regisztrálva egy FilterProviderem, abban akarom kigyűjteni ezeket a httppost metódusokat.
Magáról a metódusról meg tudom állapítani, hogy van-e rajta httppost attributum, olyat már csináltam korábban:
bool hasHttpPostAttr = (actionDescriptor.GetCustomAttributes(typeof(HttpPostAttribute), true)).Any();Köszi mindkettőtöknek, utána nézek a fentebbi linkeknek...
[ Szerkesztve ]
-
kobe24
tag
Sziasztok!
Remélem valaki tud segíteni a problémámon. Egy wpf-es alkalmazást készítek éppen, és van egy olyan része amikor vonalkódot kellene leolvasni és az alapján adatokat betölteni. Viszont a kérés az az, hogy ne kelljen mindig az input mezőbe belekattintani és úgy leolvasni a vonalkódot. Erre találtam egy megoldást a neten amit ezen a linken meg is tudtok nézni. Nagyon jól működik, ha a billentyűzeten ütök be bámifél adatot. Még egy androidos alkalmazást is letöltöttem ami elviekben a vonalkód olvasást szimulálja, és wifin keresztül küldi az adatot a gépnek. Viszont amikor már egy tényleges vonalkód olvasóval próbáltam akkor olyan billentyűleütéseket érzékelt az alkalmazás mint LeftAlt vagy a numpad1-9-ig. Ha rendesen egy jegyzettömbe vagy valamilyen input mezőbe szkenneltem az olvasóval akkor tényleg a vonalkód számát küldte el, úgyhogy nem az olvasóval van gond. Viszont nem igazán értem hogy az alkalmazásom miért vesz hibás adatokat. Esetleg ha a fenti dologra valakinek valami másfajta megoldása lenne azt is szívesen fogadnám. Köszönöm előre is a segítségeteket.
-
Pörp
senior tag
Sziasztok!
Abszolút kezdő vagyok, a billentyűzetről várok egy leütött számot, egy int változóhoz.
Addig megvan, hogy int a = Convert.ToInt32(Console.ReadLine());
A gondom az, hogy ha nem számot, hanem betűt vagy stringet ütök be, akkor kifagy. Hogy lehet eldönteni, hogy a billentyűzetről beadott karakterek azok int vagy string? -
joysefke
veterán
Az előző hsz, vagy ez, int.Parse(string)-gel, de itt manuálisan kell elkapni az exceptiont
a
bool successváltozó tárolja, hogy sikeres volt-e a beolvasás, ado-whileciklus addig fog próbálkozni a beolvasással, míg az egyszer sikeres nem lesz. A string -> int átalakítást azint.Parse(string)végzi, ha ez sikeres volt (mert a user tényleg számot adott be), akkor a következő végrehajtott utasítás a success = true; lesz. Ellenkező esetben létrejön egy exception és a végrehajtás acatch(Exception) {...}blokkban folytatódik anélkül, hogy a success változót átállítottuk volna, ebben az esetben a do-while ciklus újra lefut.class Program
{
static void Main(string[] args)
{
int num=0;
bool success = false;
do
{
Console.Write("Enter number : ");
string str = Console.ReadLine();
try
{
num = int.Parse(str);
success = true;
}
catch (Exception ex)
{
Console.WriteLine("Not a valid number, try again!");
}
} while (success != true);
Console.WriteLine($"You typed in the following number: {num}");
}
}[ Szerkesztve ]
-
-
joysefke
veterán
A válaszom tökéletesen helytálló illetve egyből működés közben mutatja be a dolgot, copy-pésztezhetően. ÉS mint följebb írtam vagy a fölötte levő hsz a TryParse(..) -val, vagy az int.Parse(..). Konzolon userre várva sosem fog számítani, ha pedig streamből jön az adat, akkor már nem az lesz a kérdés, hogy milyen metódussal lehet string->int parseolni.
-
#7934
Peter Kiss
őstag
Peter Kiss
őstag
Egy apróságot hozzátennék, ha a kérdező a Convert class-t használta: Convert.ToInt32() returns 0 when argument is null.
Az, hogy mikor mennyire fáj egy exception, kérdezd meg a processzorod L2 cache-étől.
Nyilván ebben a példában hótmindegy, nem is ez a kérdés, de mondjuk egy trading alkalmazással ahol a latency hiphop átszámolódik komoly $$$-ká, ott már nem mindegy. -
Jester01
veterán
válasz
Froclee
#7936
üzenetére
Még az is kiderülhet, hogy nem is olyan bad practice amíg az exception a kivételes esetre vonatkozik. Például a fentebb említett, "sok számot fájlból betöltök" az valószínűleg gyorsabb lesz az exception változatban, feltéve, hogy a számok jórészt helyes formátumban vannak. A normál végrehajtási irány ugyanis úgy lesz a leggyorsabb.
Jester
-
Pörp
senior tag
válasz
joysefke
#7927
üzenetére
Megcsináltam, köszönöm a segítséget. A másik módszerrel hogy nézne ki?
Köszönöm mindenkinek!using System;
class Program
{
static void Main(string[] args)
{
bool succes = false;
float num1=0;
float num2=0;
do
{
Console.WriteLine("Kérem az összeadni kívánt számokat.");
Console.Write("Egyik szám: ");
string a = Console.ReadLine();
Console.Write("Másik szám: ");
string b = Console.ReadLine();
try
{
num1 = float.Parse(a);
num2 = float.Parse(b);
succes = true;
float osszeg = num1 + num2;
Console.CursorVisible = false;
Console.WriteLine("A két szám összege= " +osszeg);
}
catch (Exception ex)
{
Console.WriteLine("");
Console.WriteLine("Nem számot adtál meg!");
}
}
while (succes != true);
}
} -
joysefke
veterán
using System;
class Program
{
static void Main(string[] args)
{
bool succes = false;
float num1 = 0;
float num2 = 0;
do
{
Console.WriteLine("Kérem az összeadni kívánt számokat.");
Console.Write("Egyik szám: ");
string a = Console.ReadLine();
Console.Write("Másik szám: ");
string b = Console.ReadLine();
succes = float.TryParse(a, out num1) && float.TryParse(b, out num2);
if (!succes)
{
Console.WriteLine("");
Console.WriteLine("Nem számot adtál meg!");
}
}
while (succes != true);
float osszeg = num1 + num2;
Console.CursorVisible = false;
Console.WriteLine("A két szám összege= " + osszeg);
}
} -
joysefke
veterán
válasz
joysefke
#7939
üzenetére
Ez float.Parse(string) helyett
bool float.TryParse(string, out float)-tal van.A kettő között a különbség az, hogy a TryParse akkor sem dob exception-t ha nem sikerült a parzolás, ehelyett a sikert a TryParse(...) fgv. a visszatérési értékével jelzi. Csak akkor, ha ha mindkét számot egyszerre sikerült parzolni lesz a success változó értéke true, ekkor tudja a vezérlés elhagyni az adatbeolvasó do-while ciklust.
-
Orionk
senior tag
Sziasztok!
JAva-ban fejlesztettem eddig.
Első munkahelyemre most mégis junior C# fejlesztőnek vettek fel, mert az interjún a C# -nak a Java "megfelelőit" tudtam.Mit gondoltok egy ilyen váltásról?
Illetve ezt a könyvet jónak tartjátok arra, hogy kezdetben ebből zárkózzak fel?
köszi
-
Szia! Én ugyan úgy junior JAVA-ról junior C#-ra váltottam, szerintem relatív "egyszerű", könnyebb mint fordítva vagy mint Cpp-re váltani.
Reiter könyv szerintem nem egy nagy durranás, Andrew Troelse - C# 2008 és a .NET 3.5 könyve sokkal-sokkal jobb. Nem kell feltétlen az egészet elolvasni, igen vaskos darab.
[ Szerkesztve ]
-
Keem1
addikt
Szerintetek mitől van az, hogy egy SQLite lekérés ugyanazzal a queryvel C# appban sokkal lassabb, mint egy adatbáziskezelőben (DB Browser for SQLite 3.10.1)?
Az SQL valami ilyesmi:
SELECT T1.field1, T2.field2, T3.field3 FROM table1 T1 LEFT JOIN table2 T2... WHERE ... LIMIT 10DB Browser: 4 rows returned in 237ms
C# console app: Kész! 00:00:01.29
MySQL (phpMyAdmin, böngészőben): Sorok megjelenítése 0 - 3 (4 Összesen, A lekérés lefutott 0.1508 másodperc alatt)Azért az is durva, hogy a MySQL böngészőben, másik gépről kevesebb mint fele idő alatt lefutott (150 ms), mint az aprócska, és helyben lévő SQLite (237 ms). Kezdek kiábrándulni a helyben tárolt adatokhoz használandó SQLite-ból.
[ Szerkesztve ]
-
Keem1
addikt
Lehet, én voltam a hülye
A második táblára rátettem egy PK-t, így 30 ms ugyanaz a lekérdezés.
Hiába, nem sikerült tökéletesen importálni MySQL-ből néhány táblát. Ezen még dolgoznom kell.Ettől függetlenül azért érdekes, hogy a DB Browsernek simán ötöde volt így is. Most 40-50 ms, az én appomban pedig 30-40 ms a lekérdezés.
A MySQL megmaradt 100 körül, de ott alapból megvolt a PK, az csak a MySQL->SQLite importkor mászott le.[ Szerkesztve ]
Új hozzászólás Aktív témák
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- ASUS ROG STRIX B550-F GAMING
- BONTATLAN Dell Latitude 5540 CTO:i7 1370P (14mag),16GB DDR5,512GB SSD,GeForce MX550,400nit 100%sRGB
- Thinkpad P15 Gen2i 27% 15.6" FHD IPS i7-11800H T1200 32GB 512GB NVMe ujjolv gar
- Dell Precision 3520, 3541 workstation notebook-ok 16-32Gb RAM, Quadro M600, P600, számla
- HUAWEI MateBook 16: Ryzen 7 5800H,16GB,512GB,16" 2.5K 2520x1680 350nit 100%sRGB,Radeon RX Vega 8
Állásajánlatok
Cég: Ozeki Kft
Város: Debrecen
Cég: Ozeki Kft
Város: Debrecen