תחומים - פורום חרדי מקצועי

הנה בדיקות כאלו בדיוק מהרשת:
לרעת לינק:
http://ox.no/posts/linq-vs-loop-a-performance-test
http://social.msdn.microsoft.com/Forums/en-US/facff412-118a-4a80-867a-66503463a638/measure-the-performance-of-a-linq-sort
http://martin.podval.eu/2010/10/c-sharp-linq-or-foreach-performance.html
http://www.alexyork.net/blog/2008/09/14/performance-of-foreach-loops-vs-linq/
http://www.codeproject.com/Articles/21934/LINQ-Performance-Test-My-First-Visual-Studio-2008http://www.dotnetscraps.com/dotnetscraps/post/linq-performance-part-1-linq-to-collection.aspx

בלוג שמדבר הרבה על זה:
http://msmvps.com/blogs/jon_skeet/default.aspx

יש הרבה כללים שנבנו מתצפיות איך כדאי לבנות את השאילתה, אבל אני חושב שהם לא כללי ברזל.
כי המסקנה היא מתצפיות, שיכולים להשתנות עקב שיפורים במנוע בכל גירסת דוט נט.

אבל יש כללים הגיוניים.
לדוגמא לבדוק אם רשימה ריקה, עדיף לבדוק ע"י פונקציית Any שמחזירה לא במקרה ריק מאשר להשוות את Count לאפס.
זה ברור כשמש, בפרט כאשר התוצאה היא שיש איברים אבל אפי' במקרה שאין.
אולי נבנה רשימה של כאלה המלצות.

פורסם במקור בפורום CODE613 ב18/07/2013 18:23 (+03:00)

@ארכיטקט

אני לא יודע איך לבדוק זאת.

יש לי רעיון פשוט, תממש את שלושת האפשרויות, תפעיל טיימר שיקבע כמה זמן לקחה השאילתה.
אחר כך לממש את זה עם לינק ולהשוות ביצועים.
תעשה את זה על מיליון או עשר מיליון איברים, ותראה את ההפרשים בבירור.
מעניין אותי לדעת תוצאות.
תעדכן....

בעבר בדקתי ככה. כל מיני שאלות שהיה לי.
אבל זה דרך מפותלת ומרגיזה.
תזכור שאם היה לי כח לכתוב כ"כ הרבה קוד, אז לינק היה מיותר בשבילי
יש כלים חינמיים לזה אבל לא הצלחתי כ"כ לעבוד איתם.

פורסם במקור בפורום CODE613 ב18/07/2013 16:56 (+03:00)

ביצועים בLinq זו שאלה כבדת משקל.
בעצם לכאורה אנו שוב זונחים את שקלולי הביצועים לטובת נוחות.
אז דבר ראשון, זו החלטה נבונה ברוב המקרים.
דבר שני, ברוב המקרים Linq יעיל בבירור.

האם אפשר לבחון/לשלוט על זה? לא לגמרי.
הגישה צריכה להיות מה ההינו עושים ללא לינק. הלינק אמור לעשות בדיוק אותו הדבר שהיינו עושים, אבל "במקומנו".
אם יש לנו מערך מספרים שלמים, ואנו רוצים רק את הזוגיים.
איך היינו עושים ללא לינק? יוצרים ליסט, עוברים בלולאה על המערך, ובהתקיים התנאי (איבר לחלק לשתיים שווה 0) מוסיפים לליסט.
זהו זה. אז לינק עושה את זה ממש ככה.

לפעמים אפשר ממש לתהות ביכולתיו של הlinq.
לדוגמה יש לנו מערך מספרים שלמים, ואנו רוצים לקחת את כל הגדולים ממאה, ובצורה ממויינת.
איך היינו עושים ללא לינק?
[u:37lq31qk]הדרך הפשוטה:[/u:37lq31qk]
א. ממיינים ע"י Array.Sort.
ב. מתקדמים מהקצה התחתון בלולאה עד שמגיעים למאה, ומשמה מעתיקים את המערך.
[u:37lq31qk]או הרבה יותר טוב והרבה יותר נחות (מתאים לאנשי C++) [/u:37lq31qk]
למיין בעצמנו, ואז תוך כדי להשמיט איברים גדולים ממאה.

אז ללינק יש שלוש אפשרויות:
א. להיות טיפש מוחלט וקודם להסיר ואח"כ למיין.
ב. למיין ולהישען על המיון כדי לסנן נמוכים (בלתי סביר שלינק עושה כך, כי הוא לא יכול לדעת שיש קשר בין קובע המיון למהות התנאי).
ג. להיות חכם ולממש לבד את המיון, ותוך כדי להסיר נמוכים.

אז הנה דוגמא שלינק יכול להיות ממש יעיל כמו מתכנת טרחן מעולם הC++. או להיפך...
אני חושב שהוא אכן חכם ויעיל, אני לא יודע איך לבדוק זאת.
לקרוא IL לא כ"כ נעים לי, כלומר אני לא יודע...
ולראות ברפלקטור זה לא עוזר, כי הוא מציג שאילתת לינק...
בימים הקרובים אולי אכתוב מהו הרפלקטור הזה על הפתעות שהוא עשה לי לפעמים.

פורסם במקור בפורום CODE613 ב18/07/2013 11:38 (+03:00)

@שמואל

האם יש אפשרות של תנאי בטריגר
זאת אומרת כפי שיש מולטי טריגר שמקבל כמה קונדישינים
האם יש גם אפשרות לקבל כמה קונדישינים ובהתאם לכל קונדישין שיתן עיצוב אחר?
תודה

בא נשווה זאת לif בC#.

המבנה של if הוא כזה:
אם X = "כן" תעשה א
אם X = "לא" תעשה ב
אחרת (else) תעשה ג

אז בWPF נעשה ככה. בסטרים של הסטייל נעשה את ג',
ונוסיף שתי טריגרים, אחד למקרה "כן" עם עיצוב א, ואחד למקרה "לא" עם עיצוב ב.

ומה אם מקרה שאנו רוצים לדעת כן/לא על ביטוי לא שויוני; לדוגמה אם X גדול מ2?
אז א"א להשתמש עם טריגר.
בשביל זה עושים קונברטר, ואז "כורכים" (בינדינג) את העיצוב לX עם הקונברטר שיבדוק כל תנאי שבעולם ולפי זה יחזיר ערך מתאים לעיצוב.

פורסם במקור בפורום CODE613 ב18/07/2013 12:11 (+03:00)

הבעיה שאצלי זה עבוד גם במקטע הCellTemplate...
(הורדתי את הפקד, וחיקיתי כמעט עד לפרט האחרון את התנהגות הקוד שצירפת).
הרעיון של הEditing זה שהוא נכנס לפעולה רק אחרי דבל קליק. אבל אפשר לשנות ערכים גם ממצב CellTemplate רגיל.

מעניין איפה הבאג, אבל העיקר שעובד.

פורסם במקור בפורום CODE613 ב14/07/2013 22:28 (+03:00)

ניסיתי משהו דומה אצלי והכל עובד. מעניין מה קורה שמה.
(דוקא לי היו בעיות עם הביינדיגים).

אם את שמה את הקומבו מחוץ לדטהגריד אם אותם הגדרות בבינדינג, הכל דופק?
ולמה מחלקה יורשת בתוך UserControl ולא ישירות הכל במחלקה היורשת או ביוזר קונטרול?

פורסם במקור בפורום CODE613 ב11/07/2013 13:12 (+03:00)

אם תעבוד כעצמאי, זה לא ריאלי כ"כ שתשב רגוע חצי יום בלי להשתגע בדעתך איך לגמור את הפרויקט, כך נראה לי, אולי אתה אדם שונה.

אם תעבוד כשכיר, בחברת תוכנה, יום שלם.
בחברה אחרת בה תעשה שירותי תוכנה (אני במצב הזה) תוכל בהחלט למצוא כזה הסדר, ובעצם אתה המלך במשא ומתן. בהצלחה!

(בקשר ל"מוסכמות במקום קוד". ניכר עליך שאתה מתכנת טוב בפוטנציה. מוסכמות במקום קוד אמור לקסום רק לאדם שכבר כתב הרבה הרבה פעמים את הקוד, ויודע בדיוק מהו ואיך הוא פועל, ומבקש להימנע ללכתוב אותו בפירוש כל עוד הוא לא כתב אחרת. הMVC, כמו גם הEntity Framwork נותנים אפשרות של "ללא מוסכמות" בה אתה שולט ברזולציה הקטנה ביותר, ושם תוכל לתת לטכנלוגיה לעבוד בשבילך בקטעים שאינך מרגיש צורך להחזיק אותם בקרנים. לא מחייב אותך לפתוח עכשיו VS (ברוב רחמנותי ) אבל אני נותן לך פתח לעתיד, ביום בו תגיד "אולי היום נעיף מבט לMVC שוב").

פורסם במקור בפורום CODE613 ב04/02/2015 12:02 (+02:00)

קשה לי לומר לך, אני אישית לא מצאתי פרנסה כעצמאי אבל אני מאוד חלש בשיווק עצמי, אני יותר טוב בתכנות :roll:

בקשר לדסטקופ וMVC. שים לב שזה השוואה לא טבעית, יש דסטקופ וWEB. ובWEB הבעיה היא חוסר כללים ולא עודף. אבל MVC זה באמת מערכת עם הנחיות עבודה רבות ומועילות, ולדעתי היא נפלאה ושווה עוד הרבה העמקה. אשמח לענות לך על שאלות עמוקות על הפילוספיה של הMVC, או על "למה צריך" ו"איך לעשות פשוט".
היום בתכנות אסור לך לדעת רק פלטפורמה אחת, אתה חייב לתת מענה ללקוח, שהרבה פעמים לא יהיה לו טוב דסטקופ ואתה תציע לו את זה בכל אופן בגלל העדר חיבור עם הטכנלוגיה/פלטפורמה השניה, וזה לא כדאי.

בהצלחה רבה ומקוה לשמוע ממך פה יותר!

פורסם במקור בפורום CODE613 ב04/02/2015 11:14 (+02:00)

בקשר לעצתו הסובייקטיבית של ארכיטקט אודות תצוגות של מיקרוסופט, קח לעצמך גם את עצתי שלי: כן להשקיע
ובהשקעה לווב אני מסכים איתו לגמרי, רק שאתה לא תצטרך לפזול כי כעת התמ"ת (סליחה הכלכלה והמסחר..) הכניסו לתוכנית את הווב חזק.

פורסם במקור בפורום CODE613 ב16/01/2014 13:30 (+02:00)

ארכיטקט! איזה בהירות!
מהיום כל מי ששואל אותי בנושא (פעם פעמים בשבוע), אני שולח אותו לפה.

גם אני מאחל לך אליעזר הצלחה רבה.
אם תלך על תכנות, מקוה שתמצא פה מענה לכל מה שתצטרך בדרך.

אם יש למישהו עוד נסיון אישי וידע בנושא הלימודים ושוק העבודה,
שיכתוב כאן לטובת כל המתעניינים.

פורסם במקור בפורום CODE613 ב11/07/2013 11:31 (+03:00)

שכחתי להוסיף את הטולטיפ,
אז בשביל טולטיפ זהה לHeader, במקום השורה דלעיל שימי את זה:

<ContentPresenter Margin="10 0 0 0" VerticalAlignment="Center" Grid.Column="1" Content="{TemplateBinding HeaderedContentControl.Header}" ContentTemplate="{TemplateBinding HeaderedContentControl.HeaderTemplate}" ContentStringFormat="{TemplateBinding HeaderedContentControl.HeaderStringFormat}" ContentSource="Header">
    <ContentPresenter.ToolTip>
        <ContentControl Content="{TemplateBinding Header}" ContentTemplate="{TemplateBinding HeaderedContentControl.HeaderTemplate}" />
    </ContentPresenter.ToolTip>
</ContentPresenter>

פורסם במקור בפורום CODE613 ב11/07/2013 20:08 (+03:00)

אהה סוף סוף עליתי על זה.
את צדקת מהתחלה.
את השורה עם הלבל בקוד של ההודעה הראושנה שלך, השורה הזו:

<Label Margin="10 0 0 0" VerticalAlignment="Center" Content="{TemplateBinding Header}" 
Grid.Column="1" />

תחליפי בזו:

<ContentPresenter Margin="10 0 0 0" VerticalAlignment="Center"  Grid.Column="1"
 Content="{TemplateBinding HeaderedContentControl.Header}" ContentTemplate="{TemplateBinding HeaderedContentControl.HeaderTemplate}" ContentStringFormat="{TemplateBinding HeaderedContentControl.HeaderStringFormat}" ContentSource="Header" />

ואז, נראה לי, שגמרנו סופית את הבעייה.
מה עשינו? החלפנו פקד לבל קשוח, שלא "מכבד" את הגדרות הטמפלט, במקורי שכן "מכבד".

פורסם במקור בפורום CODE613 ב11/07/2013 19:52 (+03:00)

סתם בשביל הטסט,
מה קורה שאת מורידה לגמרי את השורה של הטקסטבוקס בטמפלט,
ומשאירה רק את האייקון?

פורסם במקור בפורום CODE613 ב10/07/2013 21:41 (+03:00)

מעניין.
אגב למה בהרצה? בזמן עיצוב לא מופיע כלום?

פורסם במקור בפורום CODE613 ב10/07/2013 16:15 (+03:00)

עכשיו הבנתי הכל. ברור למה.
את מגדירה שהטולטיפ יציג, את תוכן המאפיין Header.
תוכן הHeader במקרה והוא טקסט, אז הוא מחזיר את הערך.
במידה והוא אלמנט הוא מחזיר העתקט של Reference לאותו אלמנט UI.
אלמנט UI יכול להיות בן של אבא אחד בלבד, אז הוא עובר דירה.

הנה המחשה חיה:

<Button x:Name="Bt1" HorizontalAlignment="Left" Margin="269,194,0,0" VerticalAlignment="Top" Width="75">
     <TextBlock Text="123" />
</Button>
<Button Content="{Binding Content, ElementName=Bt1}" HorizontalAlignment="Left" Margin="269,219,0,0" VerticalAlignment="Top" Width="75" />

אז מה עושים? צריך לכתוב את האלמנטים של הHeader בטמפלט שלו ולא בו ישירות בתור Content שלו.
ואז להציב בו טקסט פשוט.
אז במקום הקוד של ההודעה אחרונה תכתבי ככה:

<TabItem.HeaderTemplate>
    <DataTemplate>
        <StackPanel Orientation="Horizontal">
            <Image Source="..\Images\questionnare.ico"/>
            <TextBlock Text="{TemplateBinding Content}"/>
        </StackPanel>
    </DataTemplate>
</TabItem.HeaderTemplate>

ואז באלמנט TabItem תכתבי Header="שאלון...".
אז הטולטיפ יציג רק טקסט.
אם את רוצה שהטולטיפ יהיה בדיוק כמו הHeader, תעתיקי את הטמפלט הנ"ל לטולטיפ.טמפלט.
נשמח לשמוע תוצאות.

פורסם במקור בפורום CODE613 ב08/07/2013 13:37 (+03:00)

נכון, אני טעיתי מה פתאום ToolTip בControlTemplate.
אבל באלמנט הגריד (שורה מתחת) זה אמור לעבוד.
תחליפי את <Grid> ב

<Grid ToolTip="{TemplateBinding Header}">

פורסם במקור בפורום CODE613 ב08/07/2013 11:49 (+03:00)

איפה ניסית לשים את השורה הזו:

ToolTip="{TemplateBinding Header}"

?

נסי לשים אותה בתוך שורת הפתיחה של הControlTemplate (שורה רביעית).
קשה לי להבין מה קורה שם בדיוק, אולי אני צריך לבדוק את הChromTab הזה.
מחר אולי יהיה לי זמן.

פורסם במקור בפורום CODE613 ב07/07/2013 16:54 (+03:00)

לפני התעמקות בקוד, אני רוצה להבין את המטרה,
מה העניין שהטולטיפ יציג בדיוק את אותו הדבר שמוצג כבר בלשונית?

פורסם במקור בפורום CODE613 ב07/07/2013 12:44 (+03:00)

אני לא כ"כ משוכנע שמה שאמרתי הכי נכון לעשות.
בעצם מה מפריע לך במצב הנוכחי? עצם העובדה שישנו קוד במקום XAML?
כי CollectionViewSource עם הפילטר זה גם מחייב קוד שמטפל באירוע הפילטור. צריך מתודה נפרדת לכל סוג פילטור.
זה לא כ"כ זאמלי.

פורסם במקור בפורום CODE613 ב08/07/2013 14:26 (+03:00)

לא כ"כ הבנתי.
ObjectDataProvider זה רלוונטי במקרה שבשעת כתיבת הXAML ידוע לך בדיוק מה יהיו הערכים. לא הכנה לערכים דינמיים לזמן ריצה.
המקרה שלך שזה רשימות שנבנות ע"י פרמטרים יש שתי שאלות שעולות לי:
א. הפרמטרים הספציפיים למקום בו את רוצה להשתמש ידועים לך כבר בשעת עיצוב?
ב. התוצאה של הפונקציה חזויה כבר בשעת העיצוב, כלומר היא לא מושפעת משום גורם אחר שיבוא בעתיד?

אם התשובה לשתי השאלות חיובית, אז כל הפונקצייה מיותרת. צריך להשתמש עם CollectionViewSource אחד לכל תצוגה, ולהגדיר פילטר בXAML. אם תעזור דוגמא לזה אשמח להראות.

פורסם במקור בפורום CODE613 ב07/07/2013 11:55 (+03:00)