https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4303
Jakub Zawadzki <darkjames@xxxxxxxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
--- Comment #13 from Jakub Zawadzki <darkjames@xxxxxxxxxxxxxxxx> 2010-02-23 15:27:40 PST ---
(In reply to comment #12)
> Committed revision 31967.
> I don't know if it's realy worth it.
Thanks.
I create small standalone program which compare itoa() implementation:
snprintf() vs guint32_to_str_buf() (vs some others).
New one was from 3 times (-O0) to 10 times (-O3) faster.
In my test I convert numbers from 0...65_535 1000 times (snprintf 10s, new 3s)
In Linux wireshark with new packet list, col_fill_in_frame_data() (called by
show_cell_data_func) is used quite often - even when you move mouse from column
to column.
And more funny thing about guint32_to_str_buf, it's that it's called when you
select packet. (integer_to_repr() and uinteger_to_repr() called by
dfilter_macro_build_ftv_cache)
It's probably still not possible for guint32_to_str_buf() to be called about
65M times in wireshark, but I believe it wasn't 100% overkill optimization.
(even when we don't see the difference! :))
> I measured no difference in a file with
> 36 499 packets. The variation in loading time is > 400 ms so it's hard to tell.
> ( low ~4,4 s)
I believe these functions are not used much during loading file...
But anyway, imho when we have e.g. address_to_buf() it's good to use it, and
don't call ip6_to_str()?
- memcpy(&ipv6_addr.bytes, addr->data, sizeof ipv6_addr.bytes);
- g_strlcpy(pinfo->cinfo->col_expr.col_expr_val[col],
ip6_to_str(&ipv6_addr), COL_MAX_LEN);
+ address_to_str_buf(addr, pinfo->cinfo->col_expr.col_expr_val[col],
COL_MAX_LEN);
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
