Jaka alternatywa do przepisania z c#.net

0

Mam problem
Moja aplikacja działa mniej więcej tak załadowane xmle to ustawienia i dane w DB
Dwa wątki pracujące równolegle
1 pobiera dane z portu1 (gps) i wybiera odpowiednie dane z DB w zależności od odczytu
2 przygotowuje i wysyła dane do zewnętrznych urządzeń po specyficznym protokole na port2

Problem polega na tym ze maszynka na ktorym to pracuje to malenki pccik z 6 calowym dotykowcem i systemem na CF ramu 256 lub 512 (więc o plikach wymiany można zapomnieć)
System testowałem XP i embeded

Niestety kilka form watki sporo komponentów i DB zarzyna sprzęt.

Moje pytanie na jakie środowisko to przepisać (najlepiej darmowe) żeby tak nie muliło

0

najpierw moze sprawdz jakie elementy systemu najbardziej obciazaja system
i zastanow sie czy nie da sie ich zoptymalizowac, bedzie raczej prosciej i taniej

a jesli sie nie da to jedziesz C++

0

Java, tylko i wyłącznie Java w tym przypadku.

0

Ale jaki problem ma tu Java rozwiązać?

Mało ramu, lepiej iść w C++ np Qt.

0

C++ to zamulacz, robię teraz duży projekt w Javie i wiem że doskonale sobie poradzi w tym przypadku.

0

Java? Przecież tam to tylko zużycie zasobów jest szybkie :X
Zrób to w czymś natywnym, z zasady będzie lżejsze od frameworków, np C++, Delphi odpada bo nie ma nowych darmówek.
Możesz też zastanowić się nad olaniem gotowej bazy ( z tego co rozumiem to jest lokalna na maszynie? ) i zrobić własną która robi tylko to co potrzebne.

0

moze masz zbyt czeste probkowanie gps
moze za duzo lub za czesto wysylasz dane do innych urzadzen
a czy przypadkiem sama komunikacja nie trwa zbyt dlugo?
moze zapytania do bazy sa zbyt skomplikowane i trwaja za dlugo?

0

Nie wiem skąd ta niechęć do Javy, pewnie dlatego że nie umiecie w niej programować leszczyki!

0

pokaz mi platforme z maszyna wirtualna, ktora jest szybsza od nativa?
ani c#, ani java, nie byly, nie sa i nie beda szybsze od C++, chyba ze zaczna tworzyc sprzetowe maszyny wirtualne, to wtedy pewnie dorownaja programowi napisanemu w c++

0

Aż mi się przypomniała ta perełka.
To nie niechęć do Javy tylko świadomość jaka ona jest.
I z łaski swojej nie obrażaj nas gdyż to budzi niechęć.

Powiedz nam może jak pobierasz z bazy, bo te kontrolki w których wyklikuje się zapytanie to lekkie nie są. Lżejsze jest zrobione "ręcznie" przez któryś z konektorków.

Ramu strasznie mało nie jest ( chyba że tam jest więcej softu na raz odpalonego ) więc można pokombinowac żeby jedno zapytanie starczyło na dłużej.

Jak podasz schemat budowy aplikacji to może ktoś znajdzie jakiś zamulający szczególik.

0

@muh hahaha, piekna dyskusja

@MariuszAMIGA podaj jakis konkretny kod w java, ktory wg ciebie jest taki mega wydajny, a ja przepisze go do c++ i przetestujemy co jest wydajniejsze

1

Nie flejmujcie proszę... C++ jest szybszy, ale aplikacja źle w nim napisana może spowodować wyciek pamięci. Java jest zdecydowanie wolniejsza (+ narzut maszyny wirtualnej) , ale bezpieczna oraz szybka i łatwa do pisania. Wniosek? Zostań w C# ;)

Ale poważniej - języki są nieco bardziej i mniej wydajne, ale sama zmiana języka wiele nie zmieni. Pomyślałbyś raczej nad optymalizacją algorytmów i struktur danych niż na Najwspanialszy Język Świata narzekać ;)

0

Popieram

Z doswiadczenia wiem, ze 99% kodu w C# dzialajacego zle to malooptymalne algorytmy. Pierwsze co w takich przypadkach robie to lokalizuje waskie gardlo. Najczesciej to sa kiepskie zapytania do bazy lub sama zla jej struktura. Naprawde jeszcze nigdy nie spotkalem sie z przypadkiem, ktorego nie dalo sie zoptymalizowac i tak np cos wykonujacego sie 30min przepisywalo sie na cos wykonywujacego sie w 4s niezmieniajac struktury kiepskozaprojektowanej bazy danych.

Tak wiec zaczalbym od gruntownej analizy i mozliwie pomocy drugiego programisty (czesto samemu sie nie widzi swoich bledow). Chyba, ze naprawde bedziesz mial pecha i ten Twoj przypaden nalezy do tych 1%

0

Czasem usuwając efekt głupiego przeoczenia, typu tworzenie jakiegoś ciężkiego obiektu w każdej iteracji pętli zamiast przed nią, można zyskać na wydajności klika tysięcy razy.
Naprawdę poczytałbym kod i pomierzył czas wykonywania metod, może jakieś wnioski z tego dadzą się wysnuć.

0

No i przegoniliście zealota Javy, a ja tak bardzo lubię rozmowy z fanatykami :(

Z mojego skromnego doświadczenia wiem że wszystko co fajne(wygodne) w C#/.NET jest ciężkie: LINQ, Dictionary, Collections.Generic, kontrolki do baz danych także.
Przestukanie Dictionary i List<> na zwykłe arrayki daje niezłego kopa ale traci się wygodę ( odczułem to na SPOJu jakimś )

0

Rozumiem, że baza siedzi na "małym pececiku" ... próbowałeś z SQLite się pobawić? Może to właśnie silnik bazodanowy aż tyle zasobów pożera? //wolna sugestia ... nie bawiłem się jeszcze z urządzeniami mobilnymi :)

0

Ja tam podejrzewam użycie kontrolek do grzebania w bazie, one to biorą bodajże całość tabeli i dopiero wtedy selecta na pobranych danych, przez co chyba da się robić wiele różnych selectów bez ponownego pobierania danych, ale jeżeli do każdego zapytania to ma pobierać całą tabelę... brr...

0

@muh - jakie kontrolki?

0

Takie wygodnickie co ani razu nie trzeba klawisza nacisnąć, do wszystkiego wystarcza mysza.
Potem się je binduje do wizualnych tabelek i bez lini kodu masz dane z bazy na ekranie.
Nawet warunki zapytania idzie wyklikać, mało używałem tych dla WinForms ale bawiłem się tymi dla WebForms, nie są wypaśnie, są przepasione :>

0

Odkopałem projekcik z WinForms v3.5 i więcej kodu jest wygenerowanego przez VS'a do wygodnego dostępu do bazy niż mojego własnego ( osobne metdoy do zmiany każdego pola z każej tabeli zasymilowanej bazy ).
289 513 B waży kod wygenerowany dla bazy z pięcioma tabelkami, ze 20 kolumn łączne, same proste typy pól, żadnych udziwnień, tylko po jednym ID [primary autoincrement] na tablicę.
I działa powoooooooliiiiii, ale za to zamiast walić zapytaniami mogę edytowac dane przez Grida.
Dla tego projektu to było dobre ( projekt typu napisz, użyj, zapomnij - nawet nie wiem po co on mi był :> ) ale takie podejście zażyna słabszy sprzęt.

0

@msm - nie ma czegoś takiego jak szybkość języka.

@mun - domyślam się, że mówisz o DataSetach i DataAdapterach.
Osobiście tego gówna nienawidzę, dobre jest właśnie dla studenckich projektów (zresztą tak jak i c**** WebFormsy). W 10 minut wyklikasz sklep internetowy, który będzie zajebisty póki masz 3 produkty. ;)
Ale można kontrolować napełnianie danymi i wcale nie trzeba od razu ładować całej tabeli, więc wydajnościowo to nie musi być aż tak słabe rozwiązanie. Sam rozmiar kodu wygenerowanego przez designera raczej nie ma wpływu na zasobożerność aplikacji, więc to słaby wskaźnik.

Autor napisał o pamięci RAM - czy to ona jest problemem? Bo w tym opisie nie widzę niczego, co mogłoby tak zjadać pamięć.
Jak dokładniej wygląda proces? Czy po każdym odczycie z GPS coś jest odczytywane z plików/bazy? A może nie trzeba tego robić? Czy połączenie z bazą trzymane jest ciągle czy otwierane na nowo przy każdej operacji? Jaka to baza? Czy jest prawidłowo zaprojektowana (indeksy wszędzie, gdzie trzeba)? A może plik XML ma 300MB i jest obsługiwany przez XmlDocument zamiast czegoś sekwencyjnego?
Bez szczegółów można tylko zgadywać.

0

xmle laduje do DGV i DataTable
komunikacja z bazą wygląda tak

     if (Convert.ToBoolean(form1.dataTable1.Rows[i].ItemArray[93]) == true)
                    {
                        Tib[i] = Convert.ToInt16(form1.dataTable1.Rows[i].ItemArray[94]);
                    }

Sam kod generuje sporo kontrolek
to + baza = zeżarcie ramu

Jak na tkim pcciku postawić CE ?
czy w frameworku compact są duże różnice ?

0

CF jest dosc znaczaco obciety w stosunku do standardowego frameworka, brakuje wielu klas etc. ale to wszystko jest na msdn, poza tym wiekszosci z tych klas w sumie nie potrzeba na mobila lub mozna samemu napisac
hmmm jesli ladujesz duza ilosc danych to DGV i DT to sie nie dziw ze ram znika
laduj tylko potrzebne dane, jakimis porcjami, zrob stronicowanie, trzymaj dane w bardziej zoptymalizowanych strukturach danych, dbaj o usuwanie zbednych obiektow (nie trzymaj jakis referencji do nich), aby GC mogl zwolnic pamiec

0

Java rozwiąże Twój problem.

1 użytkowników online, w tym zalogowanych: 0, gości: 1