Zarządzanie pamięcią

0

Hej,

mamy taki kod:

for(int i = 0;  <10; i++)
{
int x = funkcja(i);
}

Czy będzie to zoptymalizowane przez C# czy lepiej wyrzucić zmienną x nad FOR? Proszę o komentarz

1

Jak chcesz to zoptymalizować to zrób tak:

int x = funkcja(9);

A tak na serio nie przejmowałbym się optymalizacją, to co teraz masz jest dobre z tego powodu że poza pętlą for nie dostaniesz się do zmiennej x, oczywiście jeżeli jest to pożądane.

Dodatkowo - kompilator i tak optymalizuje za ciebie więc nie ma znaczenia jak to zrobisz. Źródło

0

Dziękuję za odpowiedź.
Od razu miałbym kolejne pytanie:

foreach(Point point in points)
      {
      Node node = new Node();
      nodesPointsMap.Add(node, point);
      pointsNodesMap.Add(point, node);
      nodes.Add(node);
     }

Czy da się to sensownie zrefaktorować?
nodesPointsMap.Add(new Node(), point);
albo **tworzyć Node node nad Foreache. **
Proszę o komentarz

Pozdrawiam

1
nodesPointsMap.Add(new Node(), point);

tak nie zrobisz bo zostaje Ci jeszcze

nodes.Add(node);

Tworzenie node poza foreach też nie ma zbytnio sensu. Wydaję mi się że ten kod jest OK, zmieniłbym może lekko kolejność:

foreach(Point point in points)
{
	Node node = new Node();
	nodes.Add(node);

	nodesPointsMap.Add(node, point);
	pointsNodesMap.Add(point, node);
}
5

Czy kolega zbyt dlugo nie pisał w C/C++ ? :) (żart ofc)

Tam ludzie maja takie naleciałości aby wszystko optymalizować. Czesto to widze o znajomych ze studii ktorzy pracuja przy grach.
Tak jak mi kolega powiedzial: nie ma czasu na refaktoryzacje... optymalizacja? ooo bardzo prosze :)
To nie jest pewnie regulą (pewnie w duzych firmach jest lepiej) ale maja bardzo limitowany czas na refactoring. Kod jest pisany tak...aby gra dzialala, plynnie, potem 1-2-3 dodatki... pare patchy i do koszta po 2-3 latach (w sensie kodu). Podejscie zupelnie inne niz pisanie kodu produkcyjnego ktory utrzymuje sie czasem po 10 lat i wiecej.

Czasem w pracy takich spotykam... np mamy zapytanie Restowe... gdzie latency zwiazany z dzilalnoscia sieci i bazy trwa >500ms,
a on traci dni aby sam kod o kilka nanosekund polepszyc.
Przy okazji kod zacierajac (to bardzo duzy minus).

Nie mowie, i nie jestem wrogiem optymalizacji...ale pierwsza zasada: najpierw profilowanie i szukanie waskich gardel.
Czesto, imo bardzo czesto, lepszy jest dobry/ladny/elastyczny kod wolniejszy niz super szybki ale ciezki w dlugoletnim utrzymaniu.
Poza tym (czesto, nie zawsze) zysk 10-20% to drobnostka. Liczy sie rzad wielkosci (minimum 2-3-5 razy).

P

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